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ABSTRACT 


This  thesis  reports  on  the  design  and  implementation  of 
a  simulation  of  the  Signal  Processor  Interface  to  the 
AN/SPY-1A  Phased  Array  Radar  controller.  Inherent  to  the 
siaulation  is  the  development  of  a  representative  time 
sensitive  database  cf  the  targeting  environment*  Ihe 
programming  language  Ada  vas  utilized  as  a  program  develop¬ 
ment  language  in  the  design  for  the  database.  The  developed 
Target  Database  utilizes  the  20  mega-byte  REHEX  Data 
Sarehouse  3  200  memory  storage  unit.  The  siaulation  of  the 
Signal  Processor  Interface  mill  allow  real  tiae  testing  of 
the  Naval  Postgraduate  School*s  AN/SPY- 1 A  Radar  Controller 
System  Ncdel. 
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I-  H3BODOSUOM 


1.  BACKGB008D 

The  AEGIS  Systea  is  the  Navys  aulti-faceted 
shipboard  weapon  control,  decision  Baking,  and  surveil¬ 
lance  systea.  The  engineering  aodel  began  testing  on  the 
"Norton  Sound"  in  1977  and  the  AEGIS  Systea  joined  the  Fleet 
on  board  the  "Ticonderoga"  in  1982.  To  date,  the  AEGIS 
Systea  represents  the  newest  fielded  technology  in  the 
Fleet  and  possibly  in  the  world.  Since  every  design 

effort  aust  at  soae  tine  in  the  design  determine  what  the 
target  hardware  will  be  fcr  the  syst9a,  the  result  is  that 
all  "new  systeas"  do  not  in  fact  utilize  the  aost  current 
electronic  advances.  In  addition,  the  further  design, 
testing,  and  linking  of  the  aany  separately  developed 
and  tested  aodules  further  increases  this  unaviodable  hard¬ 
ware  gap.  In  the  ca^e  of  the  AEGIS  Systea,  this  Is 
particularly  true  since  we  have  seen  a  technological  revo¬ 
lution  cccur  during  it1  a  developeeat.  The  targe  scale 
Integrated  circuits  (LSI),  and  now  the  very  Large  Scale 
lagrated  circuits  {VLSI)  are  coeaoa  in  our  off-the-shelf 
technology.  The  Naval  Postgraduate  School  AEGIS  Modeling 
Group  has  been  investigating  the  use  of  new  off-the-shelf 
VLSI  technology  that  could  provide  significant  savings  in 
•oney  and  space  while  still  fulfilling  the  systea  require¬ 
ments  of  the  AEGIS  systea.  The  AEGIS  Modeling  Group 

decided  early  in  their  study  and  emulative  modeling 
to  choose  the  as/spt-ia  phased  Array  8adar  Controller  as  a 
modeling  subset  of  the  AEGIS  systea.  The  SPT-1A  Badar 
represents  a  sufficiently  difficult  and  real  tiae 
sensitive  module  of  the  AEGIS  systea  such  that  if  it 


can  be  successfully  eaulated,  thsn  it  should  be 
possible  tc  siailarly  build  the  other  nodules  comprising  the 
total  AEGIS  systen. 

The  AN/SPY-1A  is  a  complicated  and  extensive  system  in 
its*  cwn  right.  The  two  primary  modules  of  the  SPY-1A  Radar 
Controller  are  the  Radar  Scheduler  and  the  Track  Processor. 
Previous  thesis  work  has  been  done  to  nodel  these  two 
aodules  by  Grant  [Bef.  1]  and  Cech  [Ref.  2]  respectively. 
In  addition,  the  two  systems  that  depend  on  the  AN/SPY-1  A 
for  data  -  the  Weapon  control  System  (WCS)  and  the  Command 
and  Decision  System  (CD)  -  have  been  simulated  by  Boone 
[Bef.  3]  in  his  thesis.  The  Signal  Processor  module  is 
another  module  to  be  simulated  such  that  the  NPS  SPY-1 A 
aodel  subset  can  be  fully  interfaced  and  tested  for  real 
tine  capability  and  logical  functioning.  The  initial 
design,  development,  and  target  environment  simulation  of 
the  spt-1  A  signal  Processor  Interface  is  the  intent  of  this 
thesis. 

8.  DISCLAIMER 

Many  terms  used  in  this  thesis  are  registered  trademarks 
c£  commercial  products.  Rather  than  attempting  to  cite  each 
individual  cccestaace  of  a  trademark,  all  registered  trade¬ 
marks  appearing  in  this  thesis  will  be  listed  below, 
following  the  firm  holding  the  trademark. 

Intel  Corporation,  Santa  Clara,  California: 

Intel,  Intel  6086,  iSBC  86/12A,  BULTIoOS 

Digital  Research  Corporation,  Pacific  Grove,  California; 
CP/8,  CP/8-86,  Pl/I-86,  PL/I-80,  ED,  RAS8-86,  LINK J6, 
DDT-66 

EX^CElL^C  Corporation,  Irvine,  California: 


REMEX  Data  Warehouse 


MicroPro  international,  San  Rafael,  California: 

Wordstar 

Department  of  Defense,  Washington  D.C.: 

Ada 

Micropolis  Corporation,  Chatsvorth,  California: 

Micrcpolis 

l9ar  Siegler,  Inc.,  Anahien,  California: 

ADH-3A 

C.  PtJRPCSB  OP  THIS  THESIS 

The  broad  direction  of  the  Signal  Processor  simulation 
is  threefold: 

1.  Eaulate  the  SEI^IA  Signal  Processor  using  the  Remex 
Data  Warehouse  (a  20  aegabyte  fixed  Winchester  tech¬ 
nology  disk  system)  , 

2.  Be  able  to  emulate  the  signal  processor  functions  to 
provide  a  real  time  test  environment  for  the  SPY-1  A 
Model. 

3.  Be  able  to  use  the  simulation  to  test  the  logic  of 
the  NPS  SPT-1A  Model. 

These  broad  objectives  were  further  subdivided  into  tasks  to 
develop  a  target  database  module  and  two  system  testing 
modules.  The  first  system  testing  module  will  emulate  the 
hostile  environment  of  targets  utilizing  a  pre-developed 
target  database  while  the  NPS  SPY-1  A  Model  is  being  run/ 
tested  for  real  time  operations.  This  model  is  designed  to 
respond  as  quickly  as  possible  to  a  dwell  command  from  the 
Radar  scheduler  Module  with  an  appropriate  data  output  to 
the  Track  Processor  Module,  to  allow  an  accurate  test  of  the 
speed  of  the  overall  SPY-1A  Model.  This  design  will  be 
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herein  referred  to  as  the  “Static  Model”.  The  second  system 
will  be  used  to  test  the  logic  of  the  internal  SPY-1  A 
modules,  and  will  not  be  constrained  to  real  time  run 
requirements.  It  will  display  a  target  environment  as  it 
develcpes  and  changes  over  time,  and  allows  the  user  to 
initiate  and  change  the  environment  as  he  desires.  This 
design  will  be  herein  referred  to  as  the  “Dynamic  Model”. 
The  tasks  for  each  of  the  Modules  are  as  follows: 

TARGET  DATAEASE: 

1.  create  targets. 

2.  Develop  target  tracks  and  record  those  target  loca¬ 
tions  on  the  respective  track  at  descrete  time  inter¬ 
vals  in  the  database. 

3.  Modify  and  Delate  targets  and  target  dadta  on  the 
database. 

STATIC  Model: 

1.  Interface  database  access  with  NPS  SPY_1A  Model 

2.  Monitor  the  I/O  interface  during  tasting  without 
detracting  frca  the  real  time  environment 

DYNAMIC  Mode-: 

1.  Allow  interactive  changes  to  be  made  to  the  database 
during  runtime 

2.  display  the  tracks  in  the  database  as  the  simulation 
runs 

The  scope  of  this  thesis  extends  primarily  to  the  Target 
Database  and  Static  Model  development  and  impliaentation, 
although  the  overall  design  structure  is  such  that  the 
Dynamic  Model  can  encompass  and  utilize  the  modules  devel¬ 
oped  herein. 
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0.  THESIS  CBGehlZATICN 


The  thesis  is  organized  into  four  chapters.  The  computer 
code  developed  to  implement  the  system  is  contained  in  the 
following  appendices.  The  first  chapter  covers  the  back¬ 
ground  of  the  aegis  Project  at  the  Naval  Postgraduate 
School,  the  basic  direction  for  this  thesis,  and  thesis 
organization.  The  second  chapter  covers  the  design  of  the 
Signal  Processor  Interface  Modula.  It  will  discuss  the 
overall  considerations  for  the  design,  the  interfaces 
neccessary  between  the  Signal  Processor  and  the  ether 
■odules  previously  developed,  and  the  specific  design  for 
the  Target  Database  and  Static  Model.  The  programming 
language  Ida  was  utilized  as  a  Program  Design  language  (PDL) 
in  the  development  of  a  design  for  the  Target  Database  and  a 
Dynamic  dcdel.  The  third  chapter  will  discuss  the  implemen¬ 
tation  cf  the  design  for  the  Signal  Processor  Interface 
Nodule.  Translation  considerations  when  Ada  is  used  ns  a 
PDL  and  the  implementation  language  is  Pl/I  are  highlighted. 
The  modules  that  make  up  the  Target  Database  and  the  static 
model  are  discussed  in  detail.  Finally,  Chapter  four 
presents  some  conclusions  on  the  work  involved  in  the  design 
and  implementation  of  the  Signal  Processor  Interface  Module 
as  it  is  now,  how  it  might  be  utilized  and  changed  by  future 
Aegis  Group  members,  and  what  the  next  logical  steps  should 
be  toward  the  complete  simulation  of  the  critical  paths  of 
the  SPT-1A  Phased  Array  Sadar  Controller. 


II.  DESIGN  OF  THg  SIGNAL  PHOCggSOR  SIMULATION 
A.  OVERALL  CONSIDER ATIOHS 

i  •  Sgsiaj.as  £21  Shmss 

Tc  provide  the  desired  future  Maintainability  and 
flexibility  as  a  simulative  and  emulative  instrument#  it  is 
neccesary  to  design  the  Radar  Signal  Processor  Siaulation 
with  the  capability  for  charge.  The  latest  concepts  of  good 
software  engineering  principles  explain  that  forseeable  and 
non-forseeable  changes  are  sure  to  be  applied  to  any  soft¬ 
ware  engineering  project,  but  especially  in  those  cases  were 
the  program  being  developed  is  being  separately  designed  and 
implemented  to  become  part  of  a  larger  system.  To  provide 
that  capability#  the  designer  and  programmer  must  from  the 
start  try  tc  separate  those  items  that  are  likely  to  be 
chanced  and  use  the  concepts  of  clear  documentation  and 
structured  programming  to  make  it  easier  for  the  system 
users  and  maintainors  to  incorporate  changes.  The  decisions 
that  are  ma<*e  in  modularity  and  implementation  must  be  docu¬ 
mented  tc  enhance  the  under standability  of  the  system.  As 
much  a 8  possible#  the  assignment  of  parameters  and  constants 
should  be  clustered  or  at  least  positionally  standardized 
within  modules  to  allow  ease  in  finding  them  and  changing 
them.  The  design  concept  of  information  hiding  needs  to  be 
utilized  such  that  enhanced  versions  of  specific  implementa¬ 
tions  can  be  easily  substituted  without  causing  rajor 
changes  throughout  the  other  modules  that  constitute  the 
overall  design. 
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2.  Igsicjniiia  £or  Extensibility 


&  part  of  designing  for  change  is  the  consideration 
of  and  provision  for  extensions  to  the  basic  design  one  may 
provide.  It  is  important  to  consider  the  critical  items  in 
the  design,  and  yet  still  allow  for  the  addition  cf  ether 
modules  that  may  provide  desired  functions  for  future  users 
of  the  system.  One  way  to  provide  this  capability  in  a 
design  is  in  utilization  of  a  tre9  like  structure  that  will 
allow  the  addition  of  other  branches  at  any  node  of  the 
hierarchy.  In  so  doing,  the  designer  offers  the  maximum 
flexibility  in  the  basic  design,  and  enhances  future  main¬ 
tainability  and  changability ,  while  providing  for  the 
unforseeable. 

3 •  Modular  Design 

Incorporating  the  design  principle  of  modularity 
will  provide  the  basis  for  both  changability  and  extensi¬ 
bility,  choosing  modules  in  the  program  that  describe  a 
concise  function,  and  interface  with  each  other  without  side 
effects  will  enhance  the  under standability  of  the  design  and 
the  resultant  code.  Utilizing  ?  design  methodology  that 
incorporates  the  principles  of  top-down  design  and  assists 
in  the  partitioning  of  a  complex  problem  into  intellectually 
addressable  sub-problems  will  naturally  produce  good  modu¬ 
larity.  Boochs*  “Object-Oriented  Design"  methodology 
(Bef*  4]  discussed  in  detail  in  section  II. C  and  Appendix  E 
provides  these  attributes.  The  design  of  both  the  target 
database  and  static  model  incorporates  many  of  these  princi¬ 
ples  limited  only  by  the  author’s  designing  and  programming 
prowess. 
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B.  IHTEBFACES 


In  the  thesis  work  done  by  Riche  and  Williams  (Ref.  5], 
the  overall  design  and  modular  interfaces  were  discribed  and 
defined  fcr  all  future  SPY- 1 A  Controller  Module  development. 
However,  since  their  design  incorporates  the  development  of 
all  the  modules,  and  the  project  at  this  stage  of  implemen¬ 
tation  has  only  developed  the  most  critical  modules  required 
to  emulate  a  basic  subset  of  the  real  SPY-1  A  Radar 
Controller,  the  interfaces  they  developed  are  not  completely 
appropriate.  To  interface  with  the  dwell  commands  passed  by 
the  Radar  Scheduling  module  [Bef.  1]  and  to  pass  feedback 
that  can  be  understood  by  the  Track  Processor  module 
[Bef.  2],  the  Signal  Processor  Module  must  logically  incor¬ 
porate  the  Radar  Output,  Radar  Return,  and  Beam 
Stabilization  modules.  Therefore,  the  interface  utilized 
for  input  is  table_5 8  ("Common  Memory  Interface  between  the 
Radar  Scheduling  and  the  Beam  Stabilization  modules"),  and 
the  interface  used  to  output  is  table_8  ("Common  Memory 
Interface  between  the  Beam  Stabilization  and  the  Track 
Processor  modules")  (Bef.  5].  Hot  only  will  rhis  extension 
of  the  logical  interface  for  the  Signal  Processor  make  the 
future  work  cf  interfacing  the  modules  easier,  but  it  makes 
the  present  design  fcr  the  Signal  Processor  Interace  Module 
easier  to  implement.  The  chosen  interfaces  will  allow  the 
signal  processor  model  to  receive  and  send  target  data  in 
terms  of  cartesian  coordinates  rather  than  the  lengthy  and 
complicated  codes  that  specifically  tell  the  signal 
processor  where  to  point  its  beams.  Tables  I  and  II  3how 
the  respective  interfaces. 


TABLE  I 

Signal  Processor  Output  Interface 


/* 

OBESE:  AEGIS  MODELLING  GROUP 
DATE  OF  LAST  UPDATE;  28  OCT  81 
NODULE  TYPE:  TABLE 
PURPOSE:  CONHON  NEHORI  INTERFACE 
NANS:  E  TO  P  TABL 
*/  -  -  - 


THIS  TABLE  INTERPACES  BETWEEN  THE  BEAN  STABILIZATION 
PROCESS  AND  THE  TRACK  PROCESS 
*/ 


declare 
1  B  to  P  tabl 
2  x  3u]5  s 
y  sub  s 
2  sub  s 

BfSH 

trk_nua 


static  external 


2 

2 

2 

2 

2 


f&i  biSfll  iSitilijoJ: 

hn  jp  it  Isbiil: 

1:2  ?i  him  «* 


fixed 

fixed 


/*  END  OF  TABLE  */ 


C.  OSE  CP  ADA  AS  A  F BOG RAH  DESIG*  LANGUAGE 

Grady  Booch  [Ref,  4]  has  proposed  a  software  engineering 
design  technique  he  teras  "Object-Oriented  Design". 
Although  his  chosen  naee  for  the  design  methodology  nay  be 
unfortunate  considering  the  controversy  raised  by  the  aabi- 
guous  tere  "Object",  and  the  past  use  of  the  tern  in  refer¬ 
ence  to  the  Smalltalk  prograaaing  language,  the  design 
eethodology  itself  works  well.  Using  the  new  Department  of 
Defense  prograaaing  language  Ada,  the  purpose  of 
Object-Oriented  Design  is  to  produce  logical,  efficient, 
highly  readable  and  understandable  code  that  accurately 
reproduces  the  real  world  problea  in  the  coaputer  space. 
Ada  is  utilised  as  a  program  development  language  because  of 
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TABLE  II 

Signal  Processor  Inpat  Interface 


/♦ 

OWNER :  AEGIS  MODELLING  GROUP 
DATE  Of  LAST  UPDATE;  2  NOV  81 
MODULE  TIPS:  TABLE 
PURPOSE:  COMMON  MEMOS?  INTEBFACE 
NAME:  B  TO  B  TABL 
*/  -  -  - 


4 


HIS  TABLE  IS  THE  INTEBFACE  BETWEEN  RADAR  SCHEDULING 
AND  BEAM  STABILIZATION  PROCESSES 

*/ 


declare 

1  R.to  B  tabl  (10) 

2  search  dvls , 

*  asiS 
elev 
tiae 
4  asb 
4  Is  b 
del  idx 
boa 5  purpose 
alphl_delta_cosof£set 


3 

3 


2  trk 


3  alpha  del-  . 

?  beta  Halt  a  2os  Offset 
3  face.assir' 


Ejuse'assigfi 

stab?  coords, 

4  x  5tbl 
4  y.stbl 
4  z  stbl 
dxl  Idx 
tial, 

4  asb 
4  lsb 

beaa  purpose 

aloha  delta  cos  _ 

beta  It  It  a  SosJSffset 
face  assigB 


static  external, 

fixed  bin  (15) 
fixed  bin  (15) 

it 

15) 

_ —  .15) 

fixed  bin  (7)/ 

fixed  bin  (7) 

£«(!§) 


fixed  bin , . 

as  9 

fixed  bin 
fixed  bin 
fixed  bin 


III 


offset 


Cl 

fixed  bin 


fixed  bin 
f:.xed  bin 
f:.xed  bin 
f;.xed  bin 

m  m 


initial  jo 

initial  0. 
initial  0) 
initial  0 
initial  0 
initial  (0 

initial  (0) 

initial  (0 

!:SI:f!Si  8 

initial  0 

P 

8 


/*  END  OP  TABLE  */ 


its  capabilities  in  the  production  of  highly  structured  and 
aodularized  algorithms.  It  also  has  the  nice  feature  of 
separating  the  specifications  for  the  aodules  utilized  in 
the  design  froa  the  actual  aethods  used  for  iapleaentation 
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cf  these  acdules,  and  thus  provides  the  designer  with  an 
ability  to  postpone  the  implementation  decisions  for  as  long 
a  tine  as  convenient  during  the  design  phase.  This  feature 
was  particularly  important  since  the  programing  language 
FL/I-86  was  going  to  te  used  for  actual  inpleaentation,  and 
it  vas  intuitively  felt  that  soae  design  changes  and  conces¬ 
sions  night  have  to  be  nade  even  at  the  highest  levels 

because  cf  the  differences  in  the  large  scale  data  struc¬ 
tures  provided  by  the  two  languages. 

Object-Oriented  Design  methodology  is  broken  dewn  into 
three  basic  steps: 

1.  Define  the  Problem 

2.  Develop  an  Inforaal  Strategy 

3.  Penalize  the  Strategy 

"Defining  the  problem"  involves  the  development  of  a  concise 
paragraph  in  English  that  specifically  outlines  the  real 
world  problen.  "Developing  an  inforaal  strategy"  is  to 
develop  an  English  paragraph  that  as  clearly  and  concisely 
as  possible  describes  how  one  will  solve  the  problen.  This 

second  step  is  really  the  nost  difficult  part  of  the  method¬ 

ology,  since  the  resultant  success  of  the  design  rests  on 
how  well  this  can  be  accosplisbed  by  the  designer.  The  last 
portion  "Penalize  the  Strategy"  is  where  the  algorithm 
begins  to  take  shape.  First,  the  designer  must  pick  out  the 
proper  ncuns  that  describe  the  "objects"  of  the  solution 
strategy.  Those  objects  are  discribed  in  teras  cf  aajor 
objects  and  attribute  objects.  Next,  the  Inforaal  Strategy 
is  again  scrutinized,  this  tine  to  pick  out  the  verbs  that 
represent  the  "operations"  utilized  in  the  solution  stra¬ 
tegy.  These  operations  are  then  grouped  with  the  objects 
they  logically  affect  in  the  inforaal  strategy.  Booch  then 
would  have  the  designer  draw  an  object-oriented  system  graph 
depicting  the  objects  as  Ida  "packages"  and  the  operations 
as  Ada  procedures  and  functions  within  the  packages.  The 
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object-oriented  system  graph  describes  the  hierarchial 
interfaces  between  the  structures.  Booch  typically  includes 
an  Ada  "subprogram"  as  a  controlling  program  that  utilizes 
the  developed  packages.  Finally,  the  package  specifications 
are  written  in  Ada  utilizing  the  previously  developed 
object-oriented  system  graph  as  a  guideline  for  the  inter¬ 
facing  and  specific  procedure  specification  development. 
This  was  done  in  the  design  of  a  "Dynamic"  model  and  Target 
Database  system  and  is  specifically  shown  in  Appendix  £  for 
future  use  by  the  AEGIS  Modeling  Group. 

D.  THE  DATABASE 

Using  the  Ada  design  as  a  basis,  the  Target  Database  was 
designed  for  implementation  in  the  PL/I  and  ASM-86 
languages. 

1.  interfacing  and  storage 

The  AEGIS  Modeling  Group  experimental  computer 
depends  cn  a  32  k  byte  "common  memory"  board  on  the  MULTIBUS 
to  pass  messages.  The  common  memory  board  is  further 
utilized  for  the  commands  to  the  REMEX  Data  Warehouse  20 
mega-byte  storage  system  and  the  buffered  data  items  to  be 
written  cn  and  retrieved  from  the  REMEX .  A  mapping  of  how 
the  ccmmcn  memory  is  currently  partitioned  is  shown  in 
Figure  2.1  The  segmented  memory  base  for  the  common  memory 
is  OBOOO  hex  and  offsets  are  as  shown.  The  REMEX  Data 
Warehouse  is  also  connected  to  the  MULTIBUS  and  data  is 
transfered  to  and  from  it  in  response  to  the  formated 
messages.  The  processes  for  the  operations  of  the  REMEX  are 
discussed  in  detail  in  the  thesis  work  done  by  Almguist  and 
Stevens  [Bef.  6]  and  in  the  appropriate  manuals  fRef.  7]. 
The  basic  message  format  utilized  for  this  thesis  is  the 
read/write  format  [Bef.  8]  (as  specified  in  Pigure  2.2). 
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Figure  2.1  common  Hoaocy  Hap. 


2 .  Design  Decisions 

The  &da  design  for  the  Target-Database  resulted  in  a 
systee  that  protects  and  hides  the  actual  database  and  hov 
it  vas  implemented  free  the  user.  In  an  effort  to  incorpo¬ 
rate  that  design  feature  in  the  PL/I-86  implementation,  the 
concept  of  using  a  specific  module  to  perform  all  target 
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Figure  2.2  BE8BX  Bead/Write  Message  Format. 

data  conversion  to  an  appropriate  output  passage  foraat,  and 
then  to  perfora  the  operations  to  place  that  foraated 
aessage  in  the  BEMSI  was  conceived.  this  aodule  is  naaed 
Bld^datafcase.  Hot  only  does  it  perfora  those  tasks  just 
aenticned,  but  because  of  it*s  aodularity,  it  provides  for 
future  changes  should  the  aethod  of  storing  the  database  be 
■odified,  or  the  hardware  device  utilized  for  storage  be 
replaced.  In  addition,  the  decision  was  aade  to  stcre  only 
the  aessages  to  be  utilized  for  output  on  the  8EHEX,  rather 
than  storing  both  the  initial  target  data  that  produced  the 
aessages  and  the  aessages  theaselves.  The  reason  for  this 


decision  is  to  provide  the  fewest  number  of  REMIX  data 
seeking  operations  during  the  run  of  a  siaulation.  By 
utilization  of  a  data  structure  on  the  current  iSBC  86/12A 
in  BAM  (Random  Access  Meaory)  to  pre-build  the  proper 
sequence  of  messages,  only  a  write  command  will  b9  required 
to  retrieve  data  frca  the  REBBX.  Although  this  method 
requires  more  execution  time  during  the  creation  of  the 
Target- Database,  very  little  execution  time  is  consumed 
during  the  emulation.  The  method  utilized  for  creation  and 
modification  requires  the  partial  re-building  of  the  data¬ 
base  for  each  change  aade  to  the  Target-List  of  data. 

The  resultant  design,  modularized  for  implementation 
in  PI/I  procedures,  consists  of  the  following  (see  Pigure 
2.3)  : 

a.  Control:  This  module  contains  the  main  menu  where 
the  user  will  be  able  to  choose  how  he  will  utilize  the 
Signal  Processor  Model. 

b.  Create:  This  module  allows  the  user  to  interac¬ 
tively  construct  the  initial  environment  of  targets  and 
how  they  will  change  throughout  the  time  of  the  simula¬ 
tion. 

c.  Delete:  This  module  allows  the  user  to  delete 
targets  from  the  environment  at  any  desired  simulation 
time  point. 

d.  Change:  This  module  allows  the  user  to  change  the 
environment  during  the  initial  creation  of  the  environ¬ 
ment. 

e.  Build.  Cat  a  base:  This  module  is  not  called  by  the 
ccntrcl  module,  but  interfaces  between  the  database 
utilized  to  represent  the  environment  and  those  nodules 
utilized  through  ’•control**  to  initially  create  and 
further  modify  and  run  the  simulation.  Xt  must  be  able 
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to  build  a  set  of  output  messages  based  on  the 
previously  developed  target  data,  and  to  send  those 
■essages  to  the  8E8EX  for  storage. 


E.  THE  STATIC  MODEL 


The  design  of  the  Static  model  depends  on  the  ability  to 
read  sequentially  arranged  previously  stored  output  messages 
from  the  hard  disk.  When  keyed  by  a  dwell  command  from  the 
SPY-1  A  Track  Scheduling  module,  =.n  output  message  will  be 
placed  in  common  memory  providing  the  SPY-1  A  Radar 
Controller  system  with  feedback.  It  does  not  matter  whether 
the  output  message  offers  a  "logical"  response  to  the 
requested  dwell,  just  that  it  offers  a  response  that  will 
cause  the  SPY-1  A  System  to  send  another  dwell  command.  By 
timing  the  SPY- 1 A  System  as  it  runs  in  interface  with  the 
Static  Model,  the  user  will  be  able  to  acertain  the  real¬ 
time  performance  of  the  SPY -1 A  model  and  whether  or  not  the 
concurrent  multi processor  system  can  indeed  operate  within 
the  specifications  of  the  AEGIS  SPY-1A  Radar  Controller 
system. 

Utilizing  the  previously  discussed  target  database 
design,  a  Targe  *  Database  to  be  utilized  by  the  Static  Model 
can  be  created.  The  static  Model  consists  of  functional 
modules  that  must  be  able  to  retrieve  sequential  data  from 
the  REMEX  Data  Warehouse,  and  respond  to  each  new  dwell 
command  (tabl_58)  sent  by  the  Radar  Scheduler  with  a  set  of 
one  or  mere  feedback  messages  (tabl_8)  that  would  have 
resulted  from  a  simulated  radar  dwell.  To  enable  the  capa¬ 
bility  to  time  the  turnaround  speed  of  the  SPY-1  A  Model,  a 
CRT  display  will  be  required  th:*t  allows  measurements  to  be 
mads.,  it  is  important  that  the  display  include  only  the 
minimum  data  so  that  it  will  not  impede  the  performance  of 
the  static  Model,  and  thereby  detract  from  the  objective  of 
measuring  the  SPY-1A  System  Model  real-time  performance. 
Figure  2.4  shows  the  Static  Model  functional  modules  in  a 
hierarchial  design.  It  is  envisioned  that  the  concurrent 
activity  of  the  SPY-1A  itadar  Controller  and  tha  Signal 
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Figure  2.4  Static  Model  Design. 

Processor  Simulation  will  be  sequenced  using  the  MCQBTBX 
Operating  Systee  functions  £ae£.  9]  iapleeenting  Eventcounts 
and  Sequencers.  Thus,  although  that  interface  is  not  avai¬ 
lable  non,  th AN  AIT  and  ADVANCE  primitives  will  be  used  at 
soie  future  date  by  the  AEGIS  Modeling  Group.  In  the  aean- 
tiee,  in  keeping  with  the  design  goal  of  changeability 
(separating  and  aodularizing  those  items  likely  to  be 
changed),  the  AWAIT  and  ADVANCE  primitives  must  still  be 
incorporated  in  the  design  and  iaplsaented  for  proper  systen 
testitg. 


III.  IBPIEHBKSATZCH  OF  2  HE  SIGNAL  PROCESSOR  SIMULATION 


A.  TARGET  HARDVARE 

The  present  experimental  coaputer  systea  consists  of  a 
MULTIBUS  backplane  that  contains  enough  space  for  twelve 
(12)  Intel  S3C  86/1 2»s  (Single  Board  Computers),  four  (4) 
ADM-3  terainals  connected  to  the  four  (4)  currently 
installed  iSBC  86/1 2A  boards  and  two  different  hard  disk 
aeaory  storage  devices,  (see  Figure  3.1).  The  main  storage 
device  is  the  Reaex  Lata  Warehouse  disk  unit  (Ref.  8]  which 
contains  two  standard  8  inch  IBM  format  floppy  disk  drives 
(one  cf  which  is  used  to  boot  the  system)  ,  and  a  four  head 
fourteen  inch  Winchester  technology  hard  disk  containing 
twenty  mega-bytes  of  store.  The  other  storage  device  is  the 
MicroFolis  Hard  Disk  systea  (Ref.  10]  which  has  five  heads 
and  contains  an  additional  thirtyfive  aega-bytes  of  storage 
space.  In  both  storage  systeas,  the  user,  under  the  CP/M 
operating  systea,  is  allowed  to  write  only  to  the  disk  that 
the  terminal  device  was  initially  logged  into,  although  full 
read  capability  across  all  fixed  storage  devices  is  allowed. 
Shared  aeaory  consists  of  32K  bytes  of  Random  Access  Memory 
(RAM)  that  has  been  assigned  the  base  address  of  OEOOOsOOOO 
hexadeciial.  Occupying  or.e  of  the  twelve  board  slots,  there 
is  also  a  r.on-volative  bubble  aeaory  which  was  in  the  past 
utilized  for  the  boot  procedure  during  initialization 
(Ref.  6]  but  is  currently  utilized  as  teaporary  storage  to 
boot  the  operating  sjstea  into  each  of  the  iSBC  86/12  boards 
in  use. 

The  Intel  SBC-86/12's  use  an  8  Mhz  clock  and  contain  64k 
of  internal  aeaory  that  can  be  used  for  on  board  processing. 
Each  cf  the  ISBC  86/12’s  is  connected  to  an  ADM-3  terminal 


that  is  used  for  coaaunication.  The  operating  system  is 
Digital  Research’s  CE/H-86  [Ref.  11]  as  modified  by  previous 
thesis  students  [Bef.  6]  to  enable  the  sharing  of  peripheral 


Figure  3.1  HPS  AEGIS  Hodeling  Group  Experimental  Computer. 

devices.  There  is  an  executive  called  the  '* Multicomputer 
Baal  Time  Executive”  (NCORTBX)  [Bef.  9]  that  has  been 
written  tc  allow  fcr  concurrent  computation  by  the  SBC's. 
It  occupies  close  to  6k  bytes  of  storage  on  each  of  the 
SBC* s •  It  is  projected  that  it  will  take  aproximately  8  or 
9  SBC 's  to  carry  out  the  same  processes  that  the  four  AN/UYK 
7*s  presently  do  in  the  Spy-IA  Radar  Controller. 
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B.  SCFTIARE  DE7EL0PBE8T  ENVIRONMENT 


Recent  aguisitions  by  the  NPS  AEGIS  Modeling  Group  have 
made  the  software  Development  Environment  available  on  the 
experimental  computer  much  tetter.  The  multicomputer  system 
operates  under  the  CP/M-86  operating  system.  In  the  past, 
programing  has  teen  done  with  Intel's  PLM-86  Compiler  and 
the  ASM-86  Assembler  for  use  on  the  iSBC  86/12.  The  SPY-1  A 
major  modules  have  been  written  utilizing  the  PL/I-80 
Compiler  based  on  the  Intel  8080  microcomputer.  Now,  the 
PL/l-86  Compiler  [Ref.  12]  has  been  released  and  is  avai¬ 
lable  for  programming  use.  Because  of  the  reguirement  for 
128  k-bytes  of  RAM  for  the  use  of  the  PL/I-86  Compiler,  it 
can  only  be  utilized  by  one  of  the  four  users  at  a  time.  In 
addition,  where  in  the  past  programmers  have  gone  to  great 
lengths  tc  avoid  the  use  of  the  only  available  CP/H-86  text 
editor  ED,  the  full  screen  text  editor  WORDSTAR  is  now 
available. 

C.  ADA  DESIGN  7S  PL/I-86  IMPLEMENTATION 

The  previously  discussed  design  process  utilizing  Ada 
was  insightful  and  useful  as  a  tool  for  program  development, 
but  the  iiplementatica  language  for  the  aegis  Modeling  group 
is  PI/I.  The  primary  structure  resulting  from  the  object- 
oriented  design  methodology  is  the  Ada  "package".  The 
package  in  Ada  serves  to  promote  data  abstraction  and  infor¬ 
mation  hiding.  PL/Z  does  not  offer  a  construct  similar  to 
Ada's  "package"  structure,  but  abstraction  of  the  data  mani¬ 
pulation  and  hiding  the  fora  of  the  implemented  database  can 
readily  be  achieved.  The  modules  that  are  contained  within 
the  Ada  packages  are  written  as  a  logical  grouping  cf  proce¬ 
dures  -  the  primary  module  structure  in  PL/1.  The  subpro¬ 
gram  utilized  as  a  control  program  in  the  Ada  design  is 
logically  implemented  with  a  controlling  procedure,  the 
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'•procedure  options  (main)  "  in  PL/I.  The  Ada  package 
containing  the  target  information  is  implemented  with  the 
global  declaration  "  CEASE.  DCL"  and  the  resulting  linked  list 
used  to  develop  the  Target- List.  The  Ada  database  package 
is  implemented  with  the  PL/I  array  data-structure  "BOFFEB", 
which  is  hidden  within  the  "BLD—DAT ABASE"  procedure.  The 
"BLD^DATAEASE"  procedure  is  not  accessible  directly  to  the 
user,  and  thus  further  hides  the  form  of  the  database. 

D.  MODULES  OF  THE  TARGET  DATABASE 
1 .  General  comments 

A  useful  feature  in  PL/I  is  the  "^INCLUDE"  statement 
which  allows  one  to  make  the  compiler  include  programs  or 
declarations  that  have  been  previously  written.  This 
feature  is  most  commonly  utilized  to  include  declarations 
that  are  used  by  more  than  procedure  throughout  a  system. 
The  "global  declarations"  (DBASE. DCL)  utilized  in  the 
Target-Database  modules  are  treated  in  this  manner.  Future 
maintenance  on  the  signal  Processor  Interface  Simulation 
that  may  modify  the  Target-List,  can  be  made  to  DBASE. DCL, 
and  after  the  program  is  re-coapiled  and  re-linked,  it  will 
appropriately  affect  all  the  pertinate  modules.  In  addi¬ 
tion,  two  global  variables  within  the  functional  grouping  of 
the  Target-Database  modules  are  defined.  These  variables 
are  declared  as  "external"  initially  in  the  main  procedure 
"Control",  and  are  also  part  of  the  global  declarations 
utilized  by  the  Target-Database.  The  two  variables  are 
"delta_t"  and  "endtime",  and  should  be  noted  and  protected 
appropriately  by  any  future  changes  made  to  the  modules  of 
the  Signal  Processor  Interface  Simulation.  If  should  be 
noted  that  "delta_t"  is  not  utilized  by  either  the 
Target-Database  or  the  static  Model,  but  has  been  included 
because  it  will  impact  on  the  future  use  of  the  Signal 
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Processor  Interface  Siiulation.  It  is  'meant  to  define  the 
ratio  of  how  many  dwell  commands  are  received  versus  the 
number  cf  times  the  database  buffer  in  common  memory  is 
updated.  "Delta_t"  is  meaningful  for  the  Dynamic  Model  and 
will  impact  on  the  length  of  time  a  test  run  will  be  able  to 
run  (based  on  available  memory  space  for  a  database  and 
chosen  delta^t)  . 

2.  CONTROL .  PI  I 

The  Control  procedure  is  the  head  node  of  the 

hierarchial  structure  of  procedures  used  to  modularize  and 
structure  the  i  iple mentation  of  the  Radar  Signal  Processor 
Interface  Simulation.  It  contains  the  Main  Menu  that  the 
user  will  be  continually  coming  back  to  to  route  himself  to 
other  functional  branches  of  the  tree-like  system.  The  Pl/I 
exception  handler  OH  <condition>  <body>  is  utilized  first 
here  and  throughout  the  other  modules  to  prevent  abrupt 

program  termination  and  promote  graceful  recovery  in  the 
event  of  user  entry  errors.  Hithin  the  ON-body  a  series  of 
IP -THEN  statements  are  used.  These  will  allow  one  tc  deter¬ 
mine  in  which  interactive  block  the  error  was  committed. 
The  variable  named  "block1*  is  set  to  different  integer 
values  throughout  the  program  to  signal  where  the  user  is, 
and  where  is  the  appropriate  place  in  the  program  to  return 
the  ccntrcl,  so  that  interaction  can  continue.  The  reader 
may  be  aghast  at  the  flagrant  and  apparently  unstructured 

use  cf  "gc  to"s  in  this  and  further  modules  within  the 

On-bcdy  exception  handlers.  One  should  be  assured  that 

exception  handlers  are  probably  the  only  generally  accep¬ 
table  and  appropriate  time  to  use  the  "go  to"  in  a  struc¬ 
tured  program.  PL/I  addditionally  offers  a  further 
exception  handling  feature,  the  SIGNAL  <coadition>  command. 
When  used  in  conjuction  with  an  IP  <condition>  THEN 
<stateient>  control  command,  the  signal  command  has  the 
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effect  of  ''signalling”  the  system  that  the  defined  error 
(the  condition  of  the  signal  call)  has  occured.  The  control 
is  transfered  automatically  to  the  appropriate  ON-unit 
defined  for  that  signalled  error.  This  enables  the 
programmer  not  only  to  gracefully  react  to  defined  system 
errors,  tut  to  define  his  own  error  conditions  and  gracefuly 
continue  operations.  The  Control  module  and  the  ether 
modules  in  the  Signal  Processor  Emulation  utilize  this 
feature  to  prevent  the  user  from  entering  a  response  outside 
the  defined  allowable  range.  Finally,  the  REVERT  <error 
type>  statement  is  required  at  the  end  of  each  module  where 
the  ON  exception  handler  is  utilized.  k  stack  is  utilized 
in  PI/I  to  save  the  state  of  the  current  ON-conditicns  when 
calling  another  procedure.  PL/1-86  allows  sixteen  nested 
ON-units  on  the  stack.  Proper  utilization  of  the  REVERT 
command  will  pop  the  stack  appropriately  to  ensure  that  the 
proper  ON-unit  is  used.  Functionally,  the  Control  procedure 
sets  up  the  global  variable  "endtime'*  that  is  utilized  by 
the  other  Target -Database  modules  (create,  delete,  change, 
printlst,  and  bld^database)  to  define  the  limits  of  time  for 
which  the  database  is  to  be  constructed  on  the  REMEX  Data 
Warehouse. 

3. 

The  Create  procedure  has  the  function  of  interac¬ 
tively  contracting  a  linked-list  (the  Target-List)  of  target 
nodes  that  contains  the  data  for  the  database  of  discretely 
timed  output  messages  (tabl-8)  .  The  linked  list  utilizes  a 
pointer  to  the  header  node  (appropriately  called  "head”) 
that  will  be  used  by  the  other  modules  in  their  subsequent 
manipulations  of  the  Target-List.  The  other  two  pointers 
utilized  (tgt_ptr,  and  tgtj»kr)  are  used  to  traverse  the 
linked  list  and  manipulate  fields  on  nodes,  or  nodes  them¬ 
selves.  The  \L/I  "tlNCUJDE”  statement  allows  the 
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declaration  of  the  linked  list  structure  “Target"  without 
having  tc  declare  it  in  every  aodula  it  is  referenced.  The 
Target-List  is  implemented  as  a  linked  list  to  allow  the 
■ost  efficient  use  of  storage  during  the  run-time  environ¬ 
ment  of  the  system.  PL/I  will  only  initiate  storage  for  the 
nodes  of  the  linked  list  during  run-time,  as  required  by  the 
"ALLOCATE"  command.  Thus,  instead  of  being  restricted  to  a 
particular  array  size  (had  that  data  structure  been  used)  as 
allocated  at  compile  time,  the  user  is  restricted  to  the 
available  memory  at  that  time.  In  this  version,  the 
Target-List  is  constrained  to  56  nodes  (or  targets)  ,  since 
the  buffer  size  and  corresponding  sector  size  of  the  REMEX 
Data  Warehouse  is  fixed  at  512  bytes.  After  the  user  stops 
building  the  Target-List,  the  initial  Target-Database  is 
constructed  with  a  call  to  the  "Bld_da-cabase"  procedure. 
Note  that  the  first  parameter  to  Bldjlatabase  is  a  constant 
"1",  This  will  ensure  that  the  first  database  built  on  the 
RE8EX  begins  at  the  first  discrete  deltajt  time  value. 

<*•  mm-m 

The  purpose  of  this  module  is  to  delete  target  nodes 
from  the  Target-List  as  requested  by  the  user.  The  user  has 
previously  interactively  indicated  the  specific  discrete 
"time.in"  value  of  the  call,  and  this  information  will  be 
further  utilized  by  the  procedure  "81d_database"  in  its  call 
by  Delete.  Delete  will  request  a  target  node  number  of  the 
node  to  be  deleted  free  the  Target-List.  Then,  the  pointers 
tgt.ptr  and  tgt_mkr  are  utilized  to  traverse  the  linked  list 
until  the  appropriate  target  node  has  been  located,  when 
found,  the  target  node  is  separated  from  the  Target-List, 
and  placed  back  in  available  free  memory  store  by  the  use  of 
the  Pl/I  "FHEB"  command.  If  the  target  node  can  net  be 
found  (indicated  by  the  pointer  tgt_ptr  reaching  the  “null" 
node)  ,  the  user  will  receive  an  error  statement  and  the 
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While  lccp  controlling  this  process  will  return  the  user  to 
ash  if  there  is  another  node  to  be  deleted.  When  the  user 
has  deleted  all  the  targets  he  desires,  the  call  will  be 
made  to  the  "Bld^database"  procedure  to  re-build  the  data¬ 
base  from  the  previously  defined  delta_t  discrete  time 
increment  (”time_in”)  to  the  previously  defined  ”endtime”. 
Control  will  then  return  to  the  Main  Menu  (the  Control 
procedure) . 

5 .  CHANGE.  PLI 


The  Change  procedure  is  similar  to  the  Create  proce¬ 
dure  since  it  allows  the  user  to  re-define  the  fields  of  any 
given  node  on  the  linked  list  Target-List  in  an  interactive 
mode.  Once  again,  in  a  manner  similar  to  the  Delete  proce¬ 
dure,  the  user  will  define  the  discrete  delta_t  time  value 
where  the  Target-List  is  to  be  changed,  prior  to  the  call  to 
Change.  This  value  "time„.in”  will  be  passed  to  the 
•'Bld^databasa”  procedure  in  the  same  manner  as  with  Delete 
for  further  Target-Database  re-construction.  The  Change 
procedure  allows  the  user  to  not  only  change  the  parameters 
used  by  the  defined  parametric  equation  but  to  change  the 
equation  (and  therefor  the  shape  of  the  resultant  track) 
itself.  The  user  is  placed  in  a  while  loop  to  change  all 
the  targets  he  desires  on  the  Target -List,  until  he  indi¬ 
cates  he  is  finished.  At  that  time  the  procedure 
HBld_ database”  is  called  to  re-build  the  Target-Database  on 
the  BEMEX  Data  warehouse  from  the  time  given  in  the  first 
parameter  ”time_in”  tc  the  ”endtime” ,  both  previously  deter¬ 
mined  by  the  user. 

6.  BID  DATABASE. PLI 

This  module  is  the  real  workhorse  of  the 
Target-Database  building  system.  The  purpose  of  the 
Bld.database  module  is  to  convert  the  data  contained  on  the 
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Target-List  to  an  Array  of  output  messages  to  be  placed  in  a 
based  structure  called  "Buffer",  and  then  to  transfer  that 
Buffer  tc  another  buffer  of  equal  size  in  the  NPS  experi- 
aental  computers  common  aeaory.  At  that  tine,  the  appro¬ 
priate  aessage  will  be  sent  to  the  HEMEX  Data  Warehouse 
commanding  it  to  read  the  data  (using  Direct  Memory  Access  - 
DMA)  onto  the  required  track  and  sector  of  the  HEMEX  hard 
disk.  To  accomplish  these  tasks,  Bld_database  utilizes 
three  assembly  language  routines:  Bld_buff,  Build^cmd^mess, 
and  Send_mess.  Bld_buff  utilizes  the  pointer  to  the  struc¬ 
ture  "Buffer"  and  causes  the  structure  to  be  copied  into 
common  memory  starting  at  location  OE0OO:55OO. 
Build^cmd^mess  uses  8  parameters  to  build  an  appropriate 
BEMEX  command  message  formated  for  a  "read"  operation  into 
common  memory  starting  at  location  QBG00:5400.  Send_mess 
tells  the  HEMEX  it  has  a  command  message  at  location 
0EO00:54O0  and  verifies  that  the  REMEX  has  received  and 
responded  to  the  aessage.  Bldjlatabase  utilizes  these  three 
primitive  routines  within  two  sub-procedures 
"bld_nsg_fcuff9r"  and  "call_rdw".  The  subprocedures  them¬ 
selves  are  called  sequentially  from  within  the  .execution  of 
a  PL/I  DO  loop  that  runs  from  the  Bld^dat abase  parameter 
"time_in"  to  the  global  variable  "endtime".  The  astute 
reader  tay  now  see  why  the  user  needs  to  build  his 
Target-Database  in  a  sequential  manner,  making  deletions  and 
changes  in  a  progressively  increasing  discrete  time  incre¬ 
ment  up  to  "endtime".  If  modifications  are  not  done  in 
discrete  sequential  time,  Bld_database  will  write  over  the 
changes  that  had  been  already  written  to  the  database  with  a 
higher  value  time  increment  than  the  current  "tlme_in" 
defined.  The  sub^procedur e  bld_msg_buf fer  will  utilize  the 
Target-List  to  build  a  corresponding  output  (tabl_8)  aessage 
to  be  incrementally  placed  in  the  Buffer  structure  sequen¬ 
tially  as  the  linked  list  is  traversed.  Reaching  the  "null" 
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node  will  cause  the  while  loop  to  end,  and  a  call  tc  the 
bld_buff  priritive  routine  to  be  made.  The  x,  y,  and  z 
named  fields  for  each  component  of  the  Buffer  array  will  be 
constructed  by  the  parametric  equation  number  indicated  in 
the  Target-list.  These  parametric  equations  were  derived 
from  a  previous  thesis  work  done  by  Boone  [Bef.  3]  and  are 
utilized  here  tc  maintain  overall  SPY-1A  system  compati¬ 
bility  and  integrity.  See  Figure  3.2  for  a  listing  of  the 
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Figure  3.2  Signal  Processor  Track  Parametric  Equations. 

parametric  equations.  These  parametric  equations  can  easily 
be  changed  if  desired  by  future  users  of  this  system,  if 
specific  requirements  so  dictate  it.  The  sub-procedure 
load^rdw  uses  the  primitives  build^cad^mess  and  snd^mess  to 
cause  the  BEMEX  to  read  the  data  from  the  common  memory 
buffer.  Twe  of  the  parameters  to  the  routine  Build_emdjiess 
require  the  track  and  sector  to  be  designated  where  the 
BSHBX  will  subsequently  store  the  common  memory  buffer.  To 
ensure  that  the  track  and  sector  are  located  in  a  sequential 
and  therefore  easily  retrievable  manner,  a  set  of  simple 
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algorithms  were  devised.  The  algorithms  will  require  buffers 
to  be  stored  starting  at  a  location  indicated  by  "time_in" 
and  sequentially  building  each  of  39  sectors  per  hard  disk 
track  until  "end-time"  is  reached  or  the  memory  is  depleted 
(at  track  210).  The  algorithas  are: 

sect  *  1  ♦  mod (time_ia,40) 
track  *  1  ♦  trunc (time_in/39) 

The  "sect"  algorithm  will  convert  tiae_in  to  a  modulo  40 
number  (0-39)  and  add  1  (since  the  sectors  are  number  1  to 
39  per  track).  The  "track"  algorithm  will  divide  tiae^ia  by 
39  and  truncate  the  resultant  number  to  get  an  integer.  It 
then  adds  1  (since  the  REMBX  does  not  allow  the  use  of  track 
0  to  the  user) .  The  subsequent  calls  are  then  made  to 
fcuild_cwd_aess  and  snd^aess  in  that  order.  Upon  completion, 
Bld_datatas*  returns  to  the  procedure  from  where  it  was 
called  (Create,  Delete,  and  Chanqe)  and  then  to  Ccatrcl  to 
the  (lain  Menu  once  again. 

7.  Emmsx.qii 

The  Print„.lst  procedure  is  meant  to  be  a  tool  for 
the  user  tc  maintain  a  listing  of  the  Target^tist  as  the 
list  is  initially  created  and  as  changes  are  made  during  a 
database  building  session.  The  procedure  will  prompt  the 
user  to  turn  on  the  printer  or  hit  <control>  "P"  to  activate 
the  printer,  before  typing  "0"  to  begin  a  print  of  the 
Target^tist .  The  Target-List  print  out  will  be  initialized 
with  a  record  of  the  time  in  ("time^in")  for  proper  record 
keeping,  and  the  linked  list  will  be  traversed,  reading  and 
printing  the  fields  contained  on  each  node,  when  the  "null" 
node  is  reached,  the  procedure  returns  control  to  the 
Control  procedure  Main  Menu, 
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S.  BODOLiS  OF  THE  STATIC  MODEL 


1 .  General  Comments 

The  purpose  of  static  Model  is  to  run  through  the  developed 
Target-Database  in  as  rapid  a  aanner  as  possible,  reponding 
to  eventccunts  froa  the  SPY-1A  Model  (indicating  a  dwell 
coaaand  has  been  sent)  by  tracsfering  a  output  aessage  to 
coaaon  aeiory.  The  SPY-1  A  is  then  further  notified  that  a 
message  is  ready  for  it's  input  by  the  advancing  of  a 
corresponding  eventccunt.  The  display  of  the  Static  Model 
is  aerely  a  counter  indicating  each  data  transfer  Bade  (set 
of  output  messages)  froa  the  HBMBX  Target-Database  tc  common 
senary,  and  the  anticipated  endtiae  (or  endpoint)  for  the 
Static  Model  simulation  run. 

2*  mm-m 

The  Static  procedure  is  the  main  procedure  for  the 
running  of  the  static  Model.  The  procedure  can  operate  in 
cne  cf  tec  possible  modes,  The  first  aode  is  an  actual  run 
of  the  HES  SPY-1A  Model  as  it  will  be  eventually  interfaced 
for  testing.  It  is  assumed  that  the  MC08TBX  operating 
systee  will  be  utilized  to  enable  proper  interaction  between 
concurrent  processes,  therefor  eveatcouats  and  sequencer 
primitives  are  used  in  the  calls  herein  (which  will  be 
replaced  by  appropriate  calls  to  that  operating  system  at 
some  future  time),  to  the  meantime,  to  allow  testing  of  the 
Static  Model,  an  abut  primitive  was  written,  and  an  ADVASCS 
primitive  is  utilized  ia  the  test  program  SPTTEST.  The 
Static  Mcdel  will  loop  through  the  Target  database  in  a  PL/I 
DO  locp  from  discrete  time  1  to  endtiae.  within  the  loop, 
sequential  calls  are  made  to  AWAIT,  Load_buf£er* 
Send^cutput,  and  Display.  when  the  user  begines  a  test-tun 
with  the  SPY-1  A  Simulator,  he  will  be  prompted  to  load  that 
program  on  another  1S3C  86/12  console,  and  then  begin 
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operating.  At  that  point,  the  same  loop  will  be  run  as 
previously  described.  The  user  may  also  leave  the  Static 
Model  and  return  to  Control's  Main  Menu. 

3-  1C&C  BUFF. PLI 

The  purpose  of  this  module  is  to  extract  the  proper 
sectcr/track  combination  of  data  from  the  REMEX 
Target-Database,  and  place  it  in  the  common  memory  buffer. 
It  is  the  same  as  the  Bld_Buffer  sub-procedure  previously 
described  as  a  part  of  Bld_database,  except  the  parameters 
to  the  primitive  routine  Build_cmd_mess  are  to  "write" 
instead  cf  retd. 

4.  XIER.A86 

The  purpose  cf  this  module  is  to  transfer  a  output 
message  (tabl.8)  from  the  common  memory  buffer  to  common 
memory  location  starting  at  OEOOO:6055. 

5.  ADV1EVC.  A86 

The  purpose  of  this  module  is  to  advance  an  event- 
count  in  common  memory  to  notify  SPYTEST.PLI  that  the  output 
message  is  ready  to  be  read. 

6.  DISPLAY.  PII 

The  purpose  cf  this  procedure  is  to  send  to  the 
terminal  screen  the  "time"  corresponding  to  the  sequential 
transfer  of  sectors  of  data  from  the  REMEX  Data  Warehouse, 
and  show  the  user  the  expected  endtime  for  that  particular 
run.  This  should  enable  the  user  to  determine  the  "real¬ 
time"  capability  of  the  SPI-1A  Model. 
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F.  ASSEMBLY,  COMPILING,  AH  0  LIHKIHC 

The  assembly  language  code  was  written  in  ASM-86  and 
assembled  using  HASH-86.  This  assembler  produces  reloca¬ 
table  files  that  can  then  be  linked  with  compiled  PL/I-86 
files.  The  PL/I-86  Compiler  was  utilized  for  compilation  of 
the  PL/I  programs,  and  the  resulting  assembler  and  compiler 
".OBJ"  files  were  then  linked  using  LINK86 .  The  LINK86 
linker  enables  the  user  to  develop  a  ".INP"  file  containing 
the  list  of  program  commands  the  user  would  normally  have  to 
type  in,  and  the  linker  can  then  be  optionally  utilized  with 
the  command  "LINK86  <file  name>.INP  [INPOT]".  This  greatly 
speeds  the  link  process  and  assists  during  run-time  testing 
and  debugging.  See  [Bef.  12]  for  further  information. 

G.  TESTING 

Best  cf  the  implementation  of  the  PL/I  code  was  done 
using  Pi/I-80  instead  of  PL/I-86.  This  was  convenient 
because  of  the  extensive  availability  of  microcomputers 
using  PL/1-80  versus  PL/I-86.  Most  of  the  early  testing  was 
done  via  extensive  cede  reading  and  revision.  As  a  result, 
during  tep-dovn  testing  of  modules,  (utilizing  program  stubs 
for  the  assembly  language  subroutines) ,  the  system  worked 
with  few  runtime  errors.  Initially,  the  linked  system  did 
not  contain  the  PBINltST.PLI  code  it  now  incorporates.  This 
code  was  developed  as  a  test  routine  to  insure  that  the 
Target-List  and  the  Buffer  data  structures  were  being  built 
in  the  proper  manner  and  receiving  the  proper  data.  However 
the  program  was  perceived  as  a  desirable  tool  for  recording 
target  data  while  developing  a  Target-Database  in  the  Signal 
Processor  Interface  Simulation,  and  was  therefore  incorpo¬ 
rated  into  the  system.  The  top-down  testing  philosophy 
enabled  testing  to  be  implemented  in  PL/1-80.  This  provided 
programming  and  testing  flexibility  when  the  experimental 
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computer  became  a  contended  resource  by  AEGIS  group  members. 
The  use  of  DDT-86  (Dynamic  Debugging  Tool)  to  check  memory 
locations  and  incrementally  run  the  system  proved  tc  be  the 
most  important  tool  for  testing  and  verifying  the  signal 
Processor  Interface  Simulation  when  the  assembly  language 
routines  were  linked  and  the  experimental  computer  was 
utili2ed. 
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IV.  COSCHJSIOMS 


i.  UTILIZATION  AND  CHANG  ABILITY  OF  THE  SIGNAL  PROCESSOR 

S ISOLATION 

The  Signal  Processor  Interface  Simulation  is  a  tool  that 
can  be  cf  significant  value  to  future,  testing  of  the  NPS 
AEGIS  Group's  s  AN/SPY-1  A  Radar  Controller  Model,  The 
Tar get- Data base  system  was  developed  to  allow  it's  use  not 
only  with  the  Static  Model  as  specifically  implemented  in 
this  version,  but  also  as  the  basis  for  a  version  to  inter¬ 
face  with  a  Dynamic  Model.  The  individual  functions  that 
make  up  the  total  Signal  Processor  simulation  Sytem  have 
been  modularized  to  enhance  the  use  and  adaptability  of  this 
version  to  what  ever  future  directions  the  Simulation 
efforts  of  the  AEGIS  Modeling  Group  may  be.  A  comprehensive 
Users  Manual  has  been  provided  in  Appendix  F  for  use  with 
this  version  of  the  Signal  Processor  Simulation  as  a  stand 
alone  document.  The  only  interfacing  required  for  the 
members  cf  the  AEGIS  Modeling  Group  with  regards  to  this 
Signal  Processor  simulation  should  be  the  substitution  of 
MCOBTEX  "await"  and  "advance"  primitives  for  those  utilized 
in  this  version  of  the  static  Model,  and  the  possible 
restructuring  of  the  address  locations  in  common  memory.  It 
is  recommended  that  any  tester  of  the  NPS  SPY-1A  Radar 
Controller  Model  first  gain  experience  of  the  Signal 
Processor  Simulation  by  running  the  Simulated  SPY-1  A  Program 
"SPYTEST.CMD". 
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B.  F0TOBE  ENHANCEMENTS  AND  DIRECTION  FOR  THE  SPI-1A  MODEL 


The  next  logical  step  in  the  full  implementation  of  the 
Signal  Processor  Interface  Simulation  is  the  further  design 
and  implementation  of  the  Dynamic  Model.  The  purpose  of  the 
Dynamic  Hcdel  is  to  test  the  logic  of  the  NPS  SPY-1  A  Radar 
Controller  Model.  The  Dynamic  Model  does  not  require  the 
real-time  performance  of  the  Static  Model,  but  must  provide 
a  comprehensive  display  of  the  active  targets  representing 
the  Target-Database  at  each  discrete  time  increment.  The 
Target- Data base  system  developed  in  this  thesis  should 
provide  the  basis  for  changing  the  structure  of  the 
Target-Database  as  the  limits  of  the  logical  functions  of 
the  system  are  explored.  However,  the  Target-Database  has 
been  purposefully  designed  for  change  should  that  be  neces¬ 
sary  in  the  implementation  of  the  Dynamic  Model.  Previous 
thesis  work  by  Boone  [Ref.  3]  should  assist  in  the  develop¬ 
ment  of  the  Display  module  required  for  the  Dynamic  Model. 
Finally,  the  messages  utilized  (tables  58  and  8)  for  input 
and  output  from  the  Signal  Processor  Interface  Simulation 
will  require  some  attention.  Specifically,  the  output 
message  (table  8)  needs  to  have  some  data  from  the  input 
message  to  allow  the  SPY-1  A  Radar  Controller  Model  to  prop¬ 
erly  recognize  and  match  input  dwell  commands  with  output 
data. 


k ZUWk  k 

TABGET  SIT ABASE  PROGRAM  LISTINGS 


A.  CCNTIOL.PL  I 


Prog  Name 
Date 

ritten  by 


CONTROL  .  PLI 
May  83 

Written  by  :  Toad  B.  Rersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  is  the  main  program  to  control  the 

operation  of  the  Signal  Processor  Simulation  Target 
Database  functions  and  the  Static  Model  functions. 

V 

control: procedure  options  (main); 


declare 

create  entry 
delete  entry 


_  _  If  red,  pointer)  . 

change  entry  (fixed, pointer) , 
prinflst  entry  (pointer, fixed)  , 
static  entry; 


declare 


k  fixed  binary  (7)  , 
init  fixed  decimal  (2, 1)  , 

chclce^fixeci  binary(7). 
delta  t  fixed  decimal  (2, 1) 
endtife  fixed  decimal  (4,1) 
time  in  fixed, 
head  pointer; 


EXTERNAL, 

EXTERNAL, 


entry  errcrs  */ 


on  error  (1) 

b0#block  .  1 

put  list  (as 
put^skijJ  It 


self  (fif  .a. 
*  ini 

2  thg  .do; 


_ .  _  ,  ,.cii  (30))  ; 

st (f invalid  entry,  try  again...')* 
io_to  start; 


integer  1-6...') 


xui  u  • 

if  block  _ 

put  list  (ascii  (26) , ascii  (30) ) 
put  skip  list  ('invalid  entry, 

must  be 

to  menu; 


if  block  *  3  then  do; 

must  be  1-' ,endtime,  * . . . ') 

go  to  branch; 

,  end; 
end; 

put  list  (ascii (26)  .ascii  (30))  :  /*clear  screen  */ 
but  skip  list  ('  »♦**♦♦*  SIGNAL  PROCESSOR  SIMULATION 

*******  t) 

put  skip  list  ('  version  1.0  June  1983')  ; 


put  skip  (2)  ; 
start: 


/*  First  deteraine  vha+  the  time  interval  for  display 
updates  and  corresponding  updates  from  the  database  will 
be,  as  well  as  the  length  or  the  siaulation  */ 


blcck  *  1: 

put  skip  list  (*  SYSTEM  INITIATION:  (see  users  manual)  ')  ; 
put  skip  list  ('How  often  do  you  want  the  database  and 

the  display  updated?*)  ; 
(delta  t  range  .  1  to  1  seconds)  ')  ; 
(default  is  every  .5  sec|*)  j 


.st 

.St 

St 

t) 


I 

*  (default 
•enter  value  or 


) 


put  skip 
put  skip  __ 
put  skip  lii 
get  list  (ini  w, ,  , 

if  ( (init>1)  |  (init<.1))  then  signal 
else  dglta  t  *  init; 
put  skip  list  (•  How  aany  seconds  do  you  war.  -;  the 

siaulation  to  run?'); 

put  skip  list  (*  (endtiae  range  1 

to  (delta  t  *  8190)) '); 


0  for  default 


error  (1)  ; 


put  skip  list 


_-_Tir  .^st  ('  (default  is  300  sec)*); 
put  skip  list  {'enter  value  or  0  for  default:  ')  ; 
get  list  (Sit  1); 

if  ( (Init1>8 1901  |  finitK  1) )  then  signal  error  (1); 
else  endtiae  *  lnitl; 


/*  Next  the  user  will  be  placed  in  a  interactive 
environment  where  he  can  build  track  databases, 
run  siaulation  tests,  and  change  the  track  database 
as  he  desires  */ 


do  while  (*1'b); 

put  list  (ascii  (26)  , ascii  (30) )  ;/*  clear  screen  */ 
aenu: 

blcck  *  2: , 

put  Skip  list  ( *  ***  MAIN  MENU  ***•); 

fat  skip (2); 
put  skip  list 
put  skip  list 
put  skip  list 
put  skip  list 

*  ,4  J2> 
put  skin  list 

* 

put  skip  list 

sisiifiut “,| 

(*  After  a 
put  skip  list ( ' 
put  skip  list 

(insure  the  rest  of  the  SPY-1  Model  is  setup)'); 
put  skip  list 

{'  io)  ,Q0IT  and  return  to  the  operating  systea'); 
put  skip  list  (' (er 'er  1-6  aud  <cr»:*)j 
get  list  (choice) ; 

if  ( (choice<1)  {  (choice>6))  then  signal  error(l); 


ut  s 
ut  s 


'Shat  course  of  action  do  you  wish?')  ; 

'  (1)  CREATE  a  database  of  tracks'); 

'  (you  aust  do  this  first)*); 

DELETE  a  track  froa  the  database'); 

CHANGE  a  trock  on  the  database'); 

PSINT  the  current  target  list'); 

database  is  satisfactory  you  Bay:'); 
(5),  SON  a  siaulation')  \  1  J 


branch: 
block  ■  3; 

if  choice  *  1  then  call  create  (head)  ; 
if  choice  *  2  then  do; 
cut  sicip  list 

1'At  /hat  tiie  do  you  want  to  delete  a  target? 
get  liat(tise  in) ; 

If  f(tIae_i»<T)  l  (tiae-in>endtiae) ) 


46 


then  signal  errcr(l)  ; 


call  delete  (tiae_in,head) ; 

11  choice  *  3  then  do; 
put  skip  list 

('At  what  tiae  do  you  want  to  change  a  target?  ') 

get  list  (tiaein)  : 

if  ((tiae  InCT)  |  (time  in>endtiie) ) 

then  signal  error  (1) 

call  change  (tiae_in,  head) ; 
end ; 

f  choice  *  4  then  call  printlst (head, tiae  in); 
f  choice  =  5  then  call  static; 
f  choice  «  6  then  do ; 


put  skip(2)  list 
revert  error  (I)  ; 


***  END  OF  SIMULATION  ***•) 


step; 
end ; 

end;  /*  while  */ 
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E.  CHBATI.PII 


end  control; 

Prog  Nam  :  CHEATS.  Eli 

Date  :  May  83 

fritter  by  :  Toad  B.  Kersh 

For.  :  Thesis  (AEGIS  Modeling  Group) 

Adviser  :  Professor  Kcdres 

Purpose  :  This  module  is  part  of  the  Target 

Database  package  of  functions. 

V 

create:  procedure  (head)  ; 

/*  Global  declarations  */ 

^include  'dbase. del*; 

/*  Local  declarations  */ 


dec£ir 


_ database  entry  (fixed, pointer)  , 

i  fixed  binary  j7j. 


cent  characte 
block  fixed 


tgtnux  fixed 


er(i)  stat 

bbInIiy(Vf 


static  init('r')  , 


static  init(O)  external, 


yvel  float, 
xacel  float, 

_ _  M  _  _  i  W 


yacel  float, 
alt  float, 

tgteq  fixed  binary  (7) 


entry  errrors  */ 

"  iiitgr1 


')  s 


!?tb!oe5  EBB0B'  TBr 

ii  tick 

go  to  again; 

end; 

put  skip  list  (»»**  CREATE  TARGETS  MODULE  ***»)  ; 

/*  Initiate  the  target  list  */ 

allocate  target  set  (tgt  mkr); 
tgt  ptr  »  tgf  ikr;  ~ 
bead  a  tgt  nk?; 

tgt  ptr->nda  *  0;  /*  this  is  the  header  node  V 

allocate  target  set(tgt  mkr) ; 
tgt  ptr->next  ptr  «  tgt“mkr; 

't9't.P'tr  a  tgt_xkr;  ‘  ~ 

/*  Create  the  list  of  targets  to  be  simulated  V 

do  while  (  cont  *  'I'); 
tgtnum  *  tgtnum  ♦  1; 
tgt  ptr->nua  *  tgtnum; 
rfitlfs  * 

block  *  Is 

put  skip  list ( 'Initiate  target*', tgtnum) ; 

/*  Assign  the  target  parameters  */ 
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m 


15$’ 

Kb 


fSj 

W\i 
Is’ i 

gp 


r.f. 


K‘-l 


1 


J;< 

E 


i 

4 


I 

I: 


P  P  Parametric  Equations?  (1,2,3,or4):  ') 

get  list  (tgteq) : 

if  ( (tgteq<1)  ?  (tgteq>4) )  then  signal  error(l); 


sfcip  list('  X  range  (a)?  (-256, +256)  nm:  ')  ; 
list  (xrange).;  ~ 

(xrange<-256)  |  (xrange>256) )  then  signal  error  (1) 


put 
get 
if  ( 

put  skip  list(’  Y  range  (u)  ?  (-256  ,+256)  nm: 
let  list  (yranr**  - 


') ; 


get  list  (yrangf) ; 
if  ( (yrange<-256)  |  (yr  ange>256) )  thsn  signal  error  (1) 

put  skip  list('  X  velocity  (b)  ?  (-32, +32)  m/sec:  * ) 

?et  list  (xvel)  :  ~ 

f  ( (xvel<-32)  I  (xvel>32) )  then  signal  error  (1)  ; 

put  sfrip  list(*  Y  velocity  (v)  ?  (-32, +32)  o/sac:  ') 
Izst  (vvel)  *  ** 

if  ( (yvel<-32)  |  (yvel>32) )  then  signal  error  (1); 


ut  skip  list 


X  acceleration  (c)  ?  (-.015625,  +  . 
g®t  list(xacel): 

if  ((xacel<-.  015625)  |  (xacel>.015 


015625) m/sec/sec:  * ) 


5625)  ) 

then  signal  error  (1) 


put  skip  list 

Y  acceleration  (w)  ?  (-.015625, +  .015625)  m/sec/sec:  *) 
get  list(yacel): 

if  ((yacel<-. 015625)  |  (yacel>. 015625) ) 

then  signal  error  (1) 

put  skip  list('  Z  altitude  (d)  ?  (0,20,000)  ft:  * ); 
lisx  (d  It)  * 

if  ((alt<0)  |  (alt>2000  0) )  then  signal  error(l); 

tgt  ptr->eq  *  tgteq; 
tgt"ptr->a  -  x range; 
tgt~ptr->b  *  xvel: 
tgt~ptr->c  »  xacel; 
tgt  ptr->d  *  alt; 
tgt. ptr->u  *  yrange; 
tgt  ptr->v  =  yvel: 
tgt3ptr->v  *  yacel; 

/*  Determine  if  more  targets  are  to  be  created  V 

i!oeic:>  2: 

put  skip  (2)  list  (’create  sore  targets?  (Y  or  N) :  ')» 
get  list  (cont)  : 
if  cont  ■  *y*  then  cont  a  *  Y'; 
if  ((cont  »  '  Y')8(tgtnum°a56) )  then  do; 
allocate  target  set  (tgt  mkr)  ; 
tgt  ptr->next  ptr  *  tgt  mkr; 
tgt~ptr  *  tgtjnkr; 
end; 

if  tgtnum  a  56  then  do; 

put  Skip  list  (*  TIE  GET  LIST  IS  POLL...'); 

cont  *  * N  * ; 

enfi: 

end;  /*vhile  cont  */ 
cent  *  «  y»; 

/*  complete  the  linked  list  */ 
tgt_ptr->next_ptr  «  null; 


w: 
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tgt  ptr  *  head; 
tgt~mkr  =  head; 

/*  Build  the  Be mex  Data  Warehouse  database.  */ 

put  skip  list  ('BUILDING  DATABASE...')? 
call  bid  database  (1, head)  ; 
revert  error  (1); 


end  create; 


SO 


C.  DELETE.  FU 


frog  Name  :  DELETE.  ELI 

Date  :  May  83 

Britten  by  :  Toad  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Ko^res 

Purpose  :  This  nodule  is  part  of  the  Target 

Database  package  of  functions.  It  deletes  targets 
from  the  Target  List. 


delete:  procedure  (tine  m,head)  ; 

^replace 

true  by  •  1  ’b. 
false  by  *  0*  d  ; 

/*  Global  declarations  */ 

^Include  'dbase.dcl1; 

/*  Local  declarations  */ 

declare 
bid  da 
fguSd 
tine 


base  entry  (fitted, pointer)  , 
t(1)  static  imt  (false) , 
tine  in  fixed. 

tgtmJm  fixed  binary (7)  external, 
tgt  fixed  binary  (7). 
cont  character  (1)  static  init(*Y'); 

/*  This  exception  handler  will  take  care  of 
all  user  input  errors  */ 


i  list  (»ENT  BY  EBBOB,  TBY  AGAIN 
try; 


on  err<?r  (1) 
begin; 

put  ski) 

.go  to  rl 
end: 
tgt  *  0; 

put  skip  list  ('*«*  DELETE  TABGETS  MODULE  =«')! 

/*  This  will  initialize  the  Target  linked  list  to  the 
correct  nenory  space  */ 

tgt  ptr  *  head->next  ptr; 
tgt“nkr  a  head; 

/♦  This. jiil. delete. the  desired  node  froi  the 


del< 

1  list  ♦/ 


target  linked 

•Y») ; 

list 

f*  Shat  target  do  you  wish  to  delete?  ♦): 
list 

(tgt.  nun.  range  1-* , tgtnua,  •)  :  »)i 

ir 

dc 


do  while (  cont  ** 
retry: . 
put  skip 

put  skip 

list 
( (tgt« 


:gt>tgtaua) )  then  signal  error  (1)  ; 


lo  while  (found  *  false); 
if  tgt  ptr->nua  *  tgt  then  do; 
tgt_Sfcr->next  ptr  *  tgt  ptr->aext  ptr; 
tgt"ptr->nextjJtr  *  null; 
trew  tgt  pt retarget ; 
tgt  otr  *  head-Onext^ptr; 
tft^akr  *  head; 
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found  -  true; 

end; 

else  do: 

tgt  akr  *  tgtptr; 
tgfptr  »  tgt  akr->next  ptr ; 
if  fgt  pt^  *  null  then  lo; 
put”skip  list 

(’ERROR  :  target 
tgt  ptr  =  head->next  ptr; 
tgt  akr  ^  head; 
fould  *  true; 
end; 

end; 

end;  /*  while  */ 
found  *  false; 


put  skip  list(’ 
get  list  (cent)  ; 
if  cont  =  *y *  t 


end;  /*vhile*/ 
cont  *  *  Y'; 


list  ( ’continue 

_  - —  4  *  • 

£hen  cont 


(Y/N)  ?  •) 


•  Y’; 


number  not  found') 


put  sfrip  (2)  list  ('BOILDIMG  HER  DATABASE, 
call  tla  database  (tiie  in#head)  ; 
revert  error  (1); 

end  delete; 


D.  CHABGI.  ELI 


Prog  Naae  :  change.  Ell 

Date  :  May  83 

Written  by  :  Toad  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Adviser  :  Professor  Kodres 

Purpose  :  This  nodule  is  part  of  the  Target 

Database  package  of  functions.  It  changes  data 

on  the  Target  List. 


change:  procedure  (tine_in,  head) ; 

^replace. 

*  z\ 


rue  by  *  1  *b, 


false "ly  'O' 6; 

/*  Glcbal  Declarations  */ 


Xinclude  *dbase.dcl*; 

/*  Local  Declarations  */ 


declare 

aore*"bit  (1)  static 
tgtnus  fixed  binar 
“  ’I  fixed  binary (7 
,chg2)  fipd 
Pch|4  ,chg5,ch 


t  y  t  u  «  8 

tgt  fi: 

0hgl,< 


(fixed,  pointer) 

is  it  (true) , 

(7)  external, 

in  a 


H  fWUUJ  ,V*U  VJU  <  VUVJ  f 

)  asj|tic  i^it  (fa 


6,  Ml 


8,chg9)  float. 


eck  fixed  binary  (7)  ,  ' 

character  (i)  static  initf'y*) 


/*  This  exception  handler  will  take  care  of  all 
user  input  errors  v 


on  error  (1) 
begin; 

if  SoJS 

go  to 

end ; 


list  (•  EH?  8* 
*  1  then 

try2; 


EBBOB, 


TS*  AGAIN* . . ')  ; 


put  Skip  list  (•***  CHANGE  TA8G8TS  MODULE  *»a*)  ; 

/*  First,  guery  the  user  about  the  changes  to  be  »ade  */ 
do  vhilelcont  *  *  t*) ; 

Sllci  .  1 : . 

put  skip  list 

i*  What  is  the  target  nutber  you  wish  to  change?*); 
put  skip  list 

<*  (tqt*  nue.  range  1-*  ,totnu«, :  *H 
get  list  (tgt)  ; 

if  < (tgt<tf  i  (tgt>tgtn ue) )  then  signal  arror(l); 

What. data  its  a.  is  to  be,  changed?* ) : 


ut  skip  list 
ut  skip  lilt 
put  skip  list 
get  skip  list 
If  ((chgKi)  I 


)  then  signal  error(l)  ; 
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(chg2>4))  then  signal  error  (1); 


if  chgl  *  1  then  do; 
do  1  =  true: 
put  skip  list 

(*  What  is  the  new  equation  number  (1-4)?"); 
get  Iist(chg2)  ; 
if  ((chg2<1  f j(c 
end; 

else  do; 
try2: 

block  «  2; 
dol  =  false; 

st  (• 


III  Sill  lift 
?r  (HEgiS-ii’ef 


What  are  the  new  parameters:’) 
X_range  (a)?  {-256, +256)  nm:  ’) 
|(chg3>256))  then  signal  error(l) 

put  skip  list 

'  Y_range  (u)  ?  (-256  ,+256)  nm:  •) 

get  list (chg4) ; 

if  ((chg4<-256)  1  (chg4>256) )  then  signal  error  (1) 
put  skip  list 

(’  X  velocity  (b)  ?  (-32, +  32)  m/sec:  *) 

get  list  (chg5)  j” 
if  ((chg5<- j2)  I  (chg5>32) )  then  signal  error  (1)  ; 

put  skip  list 

(’  Yjrelocity  (v)  ?  (-32,+ 32)  m/sec:  ’)  ; 

?fX((chgi<-f2|  [  (chg6>32) )  than  signal  error  (1)  ; 
put  skip  list 

X_acc4l.  jo)?  (-.015625, +  .015625)  m/sec/sec;  '); 

?ftacfg?<-?o\§625)  |  (chg7>. 0  15624)) 

then  signal  error  (1); 


put  ski 
la" 


:  list 

11  m 


Y  accei.  jw)  ? 


((chgfc 


(-.015625,  v .015625)  m/sec/sec:  • ) ; 
25)|  (chg8>. 0156  25)) 


3Ut  S 

jet  1 
If  ((chg 


end; 

tgt  ptr  =  head->next  ptr; 
tgt”akr  »  head; 


then  signal  error  (1); 
*(’  Z.alt.  (d)  ?  (0; 20,000)  ft:  '); 
(chg9>20000) )  then  signal  error  (1); 


w  this  will  find  the  desired  node,  and  make  the 
sted  changes  on  the  target  data  list  V 


/*  NO 
regue 


do  ^hi^ejmore 


true)  * 

.gt  ptr->num  *  $gt  then  do; 
if  3o1  *  true  then  tgt  ptr->eg 
else  do; 

tgt  ptr->a  *  chg3 
b  •  chgS; 


chg2; 


tgt"ptr->c  «  cl 
tqt  -  -1 


ig7 

,  itr->u  *  chg4 
tgt  btr->v  »  chg6 
tgt  5tr->w  *  chg8 
tgt  ptr->a  *  chy9 
aid; 

more  *  false; 
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■ .  •  ‘  - ,%  , 

a.  iiL  >  a 


end; 

else  do; 

tgt  mkr  »  tgt  ptr; 


a*; 


.  'ptr  *  tgt“akr->next  ptr; 

Egt  ptr  =  null  then  do; 
put~skip  list 

( ' EREOS  ;  target  number  not  found'); 
tgt  ptr  =  head->next  ptr ; 
tgt  akr  =  head; 
acri  =  false ; 
end; 
end; 

end;  /*  while  */ 
aore  *  true; 

put  skip  (2)  list  . 

('Dc  you  wish  to  change  another  target?'); 
put  skip  list  ('  (Y/N):  •)  ; 

get  list  (cont)  ; 
if  cont  »  *y '  then  cont  =  *Y'; 

end;  /*  while  V 
cont  *  'Y*; 

put  Skip  (2)  list  { 'OPDATI  NG  CHANGED  DATABASE...'); 
call  fcia  database  (tlae  in, head); 
revert  efror  (1) ; 


end  change; 


£.  BIDBE1SE.PLI 


Prog  Name 
Date 

Written  by 
For 

Adviser 
Purpose 
database  in 
Target  List 
V 


BLDDBASE.PLI 
May  83 

Toad  B.  Kersh 

Thesis  (AEGIS  Modeling  Group) 
Professor  Kodres 

This  is  the  module  the  builds  the 
the  Remex  Data  Warehouse  after  the 
has  been  created  or  modified. 


bid  database:  procedure  (time  in, head); 
TEreplace 

true  by  *  1 *b. 
false  By  'O'B; 

/*  Global  Declarations  */ 

Sinclude  'dbase.dcl*; 

/*  Local  Declarations  */ 
declare 

timeend  fixed, 

time  in  fixed  binary(15), 

t  fixed  binary  (15)  , 

trkful^  char ( i )  static  init  (•»'), 


/*  This  irain  procedure  uses  subprocedures  to  build 
the  database  cr  table-8  structutes  m  the  Remex  Data 
Warehouse  */ 


t  *  tiae_in 


tieeenS  a  trunc  (endtiae/delta  t)  ; 
do  i  *  time  in  to  timeend; 

cal^  bld“«s<j^  buffer (head,t)  ; 

t  ■  t1??!1  <t); 

if  trkfuli 
end; 


«  ‘I1  then  return; 


/*  This  procedure,  will  create  the  Signal  Processor 
Interface  Simulation  output  message  to  the  Track 
Processor  Module  for  each  node  of  the  target  list, 
and  store  them  in  a  buffer.  */ 


tld^eag^buffer:  procedure  (head, time,. in)  ; 
declare 


/*  The  Buffer  contains  all  the  track  tables  at  time^in  */ 
1  Buffer  static. 


/•  Table  8:  interfaces  between  the  beam 
stabilization  process  ana  the  track  process  */ 


2  B  to 


3  y  sub“s  fixed  b; 

3  z“sub  s  fixed  bin! 

i  RrtBM&v1, 

3  trk  nua  fixed  b; 


$ 

0 

0 


declare 

tld_bu£f  entry 


(1, 2  pointer. 
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2  bit  (16), 

2  bit  (16j )  ; 


declare  . 

tue  in  fixed 
head”pointer; 


binary  ( 15) 


declare 

acre  bit(1)  static  in  it  (true), 
ctr  fixed  binary(7), 
egu  fixed  binary  (7), 

<x,y,z)  flcat; 


dec^ 


are 

parablk  static, 


2  sourcebuff  pointer, 

2  destbuff  titM6)  init  (•  5500*  b4)  , 
2  segaddr  bit(16)  init(*e000’b4)  ; 


ctr  *  1; 

/*  First  get  the  ncde  of  the  target  data  list  and 
extract  the  data  needed  to  generate  the  items 
on  tbl  8  */ 

tgt  ptr  *  head->next  ptr; 
tgt~ikr  =  tgt_ptr;  ~ 

do  while  (more  *  true)  ; 


buffer 
equ  a 


b_to  o  tabl(ctr) .trk  nua  a  tgt  ptr->nua; 
tgt„ptr->eg; 

/*  Derive  values,  for  target  .positions tx,y, and.  z 
at  time.in  for  the  specified  paraaetric  equation  */ 

if  ecu  *  1  then  do:  ... 

x*tgt  ptr->a  ♦  tgt  ptr->b*tiae  in 

tgt  ptr->c*tiae  in*tiae  in; 
tgt  ptr->v*Ilae  in 

tgt«ptr->w*tiae_in*tim9-in; 


y*tgt-iptr->u  ♦ 

z»tgt  ptr->d; 
end; 

if  equ  »  2  then  do: 

x*tgt„ptr->a  ♦  tgt^ptr->b*tiae. 


in 


tgt,ptr->c*tiae-.in*tiaa  in; 
y*tgtwptr->g  ♦  tgt_ptr->v*Sln (tgt  ptr-^wtiae  In); 
z»tgt  ptr~>d; 
end; 

if  equ  ■  3  then  do; 

end; 

if  equ  *  4  then  do: 

x*tgt  Dtr->a  ♦  tgt  otr->b*cos(tgt  ptr~>c*tiae  in); 
y*tgt_ptr->u  ♦  tgt  jptr->v*sin(tgt.jptr->v*tlae  in); 

end; 


fcui 

fcu: 

C'J ! 


far.  b^to^p^tab:.  (ctr)  .x  sub 
cer.fc  to_p tab;.  ctr).y“sup” 
cer.b  to.p  tab!  (ctr)  .z“suEr 


s  ® 
s  * 

S  a 


*; 
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/*  Set  up  tc  look  at  the  next  target  */ 


ctir  28  ctr  ^  1 # 

tgtj?tr  =  tgt’mkr->next  ptr; 
tgt  mkr  =  tgt“ptr; 
if  fgt  ptr  =  Hull  then  more  * 
end;  /*dc  while*/ 
more  =  true? 
tgt  ptr  *  head; 
tgtskr  =  tgt  ptr; 


false; 


/*  This  will  transfer  the  buffer  structure  to  the 
common  memory  board  buffer  location  for  transfer 
to  the  REHEX.  */ 


parablk.scurcebuff  =  addr (buffer)  ; 
call  bld_buff  (b„ptr) ; 

end  tld_®sg_buff er; 

/*  This  procedure  will  cause  the  REMEX  Data  Ware¬ 
house  to  load  the  contents  of  the  buffer  into  the 
next  sector  on  the  ROW  hard  disk.  */ 


load_rdw:  procedure  (time_in) ; 


declare  . 

time  m  fixed , 
sand” ness  entry, 
build  cmd  mess  entry 


declare 

status 


,  fixed 
binary 
inary 


lxed  binary  IS,  f 


binary  (15) 

3?) 


fixed  binary (7) 


fixed,  binary 


sect  fixed  binary 


word., 
mem  15 
asb  b 
track 


;cunt 

t(16 

hhs 

fixe 


static  init  (0) , 

init  (256)  , 


r?>(15) 

fixed' binary  (15) 
static  init  (’55 
static  init('00 
_  _ _  „  binary  (15 ) , 

iU'rftTCitiUFi&tle  initc  1020  .M)  : 

/*  wl020w  means  the  REMEX  will  wri 
from  the  com. mem.  buffer  to  the  har 


static 
J00*b4)  , 
'000e  *  b4)  ,r 


disk.*/ 


h*  ad  »  0;  /*  this  sets  head  to  “O'*  drive  */ 


/*  This  determines  the  sector  based  on  39  sectors/track  */ 
sect  ■  1  ♦  mod(tiaejin,4  0)  ; 

/*  This  determines  the  track  */ 


track  *  1  ♦  trunc  (tine^in/39)  ; 

/*  need  except,  hndler  for  TRACK  >210  */ 


if  track  >  210  then  do: 

put  skip  list(*The  database  store  is  full.*); 
put  skip  list 


put  s 


>Slist  iS  recor<ie<3  as  Stime^in,*  delta_ts.*) ; 

(*  To‘cr«ate‘a  longer  run,  change  the  value  of  delta  t.*); 
trkfull  ■  *T» ;  ” 

return; 
end; 


/*  This  procedure  builds  the  command  message  required 
for  the  REMEX  Data  Warehouse  to  read  the  data  tables 
located  in  the  buffer  corresponding  to  the  value 
of  Mtime_inM.  */ 

call  build  cmd  mess 

{rdv_read#s£atusftrac)crh€ad,sect,  memrasb, vord_count) ; 

/*  The  procedure  sends  the  command  .message  to  the  9emex 
Data  Safehouse  to  perform  the  required  read  operation  */ 

call  sendjaessj 

end  lcad_rd«; 

end  bld^database; 


F.  PHI  MIST.  PL  I 


Prog  Bane  :  PRINTLS1.PLI 
Data  :  May  83 

Britten  ty  :  load  B.  Kersh 
For  :  Thesis  (AEGIS 

Advisor  :  Professor  Kodr 
Purpose  :  This  module  is 
the  user  to  keep  a  record  o 
List  as  changes  are  made  at  each  delta  t,  as  a  Target 
Database  is  constructed  for  a  Static  MSdel  run. 

*/ 


Modeling  Group) 
es 

a  diagnostic  tool  for 
f  the  flow  of  the  Tarcret 


pri8! 


1st:  _pro^|dure 


ncludl 


- (head, time) ; 

ase. del' ; 


declare^  ,  , . 

prt  fixed  bin  (7), 
time  fixed, 

(head, ap, bp)  pointer; 


put  skip  list  («===  PRINT  TARGET  LIST  *=*•)  ; 
retry: 

put  skip  list  (‘To  get  a  print  out.  turn  on  printer, 
put  skip  list (‘type  <ctrl>  P,  and  then  type  0<return>. 
put  skip  list  (‘  Else,  just  type  0<return>.  * )  ; 


ien  go  to  retry; 


put  skip  (2)  list  (‘TARGET  LINKED  LIST  at  time  *  ',tiae) 
ap  *  bead; 
bp  *  ap; 

ap  *  bp->next  ptr; 


do  while  (ap°*null) ; 
bp  *  ac: 


put  sk 
’'Mt  sk 


iis  a 

put  skip  list 
put  S1,7''  1  4 
s 


put  aitjup  xiai. 
put  skip  list 
put  skip  list 
put  skip  list 
put  skip  list 
An  *  bp->next 
bile  */“ 


f* 


ap  - 
end; 


5! 


*TGT  : 

::  eq 

•,ap->num)  ; 
'  ,ap->eq) 

’  a 

; ,ap->a 

'  *  b 

'  ,ap->b 

1  *  c 

•  ,ap">c. 

‘  u 

•  ,ap->u 

•  y 

* ,ap->v 

*  w 

'  #ap->w 

r  a 

-F^r; 

*  ,ap->d' 

b 


Had! 


end  printlst; 


6.  DEASI.DCI 


Prog  Same  :  DBASE. DCI 

Date  :  May  83 

Britten  by  :  Toad  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  These  are  the  global  declarations 

for  the  Target  Database. 

V 


declare 

declare 


endtiae  fixed  decimal  (4,1)  external 
deltajt  fixed  decimal  (2,1)  external 

head  pointer. 


pointer. 


2 

2 

2 


ua  ::ixed  binary  (7)  , 
g  fixed  binary  (7) , 


n 

eg 
para. 


3 

3 

3 

3 

3 

3 

3 

3 

3 


a  float, 
b  float, 
c  float, 
u  float, 
v  float, 
w  float, 
float. 


e  float, 
f  float, 

2  next  ptr  pointer; 


B.  BLDB0FF.A86 


Prog  Name  :  BLDBUFF.A86 

Date  :  4  June  83 

Written  by  :  Todd  E.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  routine  will  transfer  a  256  word 
buffer  from  SBC  priyate  memory  to  the  com. 
memory  buffer  starting  at  EGQu:51Q0.  The 
parameter  passed  is  a  parameter  block  containing 
a  pointer  to  the  buffer  on  SBC,  and  the  base 
ana  offset  to  the  common  mem.  buffer. 


Code  Segment_ 

This  routine  assumes  parameters  as  follows: 
paral  parameter  block  consisting  of 
3  words. 

cseg 


bid  buff: 
“push  ax 
push  si 
push  di 
push  cx 
push  es 
mov  si, 
mcv  si, 
mov  di, 
les  di- 
mov  ex,  256 
move  words: 
lev  ax, 
mov  es 


bx 


si 


bx 


W). 


ax 


inc 
inc 

inc  di 
inc  di 
loop  move  words 
pep  es 


get  location  of  buffi 
from  para,  passed 
assign  location  of  buff2 

;  assign  no.  of  words  to  move 

lead  word  from  source 
;  store  word  into  com. mem.  buffe 
;  adjust  pointers. 


;  loop  if  not  dona 


APPENDIX  B 

STATIC  HO DEL  PHOGRAH  LISTINGS 


A.  STATIC.  PU 


Prog  Name  :  STATIC.  FLI 

Da^e  :  8  June  83 

Written  by  :  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  module  controls  the  operation  for 
the  B CP  static  Hodel. 

*/ 

static:  procedure; 
declare 

load  buffer  entry  (fixed)  , 
xfer  msg  entry, 
advance  evcl  entry, 
display'entry  (fixed)  . 
await  entry  (fixed  binary(15)); 


display'*entry  (fixed) , 

await  entry  (fixed  binary(15)); 

declare 

start  fixed  binary  (7)  , 

thrshcld  fixed  binary  (15)  static  init(1), 
endtime  fixed  external, 
item  fixed  binary  (7)  , 

eycvalue  fixed  binary  (15)  static  init(O)  external, 
tine  fixed; 

/*  This  exception  handler  will  take  care  of  all 

user  input  errors.  */ 

on  error  (1) 

*9put  skip  list  ('ENT  BY  ERROR,  TRY  AGAIN...'); 

gc  to  retry ; 
end; 


put  skip  (ascii(26) , ascii  (30)):  /*  clr.  screen  V 
put  skip  list  (*  ««*  RSP  STATIC  MODEL  ■«•); 

put  sk  p  list  ('  version  1.0  June  83*); 
put  skip  (2)  ;  , 

put  skip  list  (*  At  this  pcint  you  should  have  created 
a  database  and  are  now  ready  to  run')  ; 
put  skip  list  ('your  test  of  the  NPS  SPY-1A  Model. ')  ; 
put  skip  (2)  ; 


and  return  to  mai 
!  and  <cr>:  ') ; 


ienu' )  ; 


put  skip  list  ('your  test  of  the  NPS  SPY-1A  Mode] 
put  skip  (2)  ; 
v qtt v • 

put  Skip  list  (*  *■*  STATIC  MODEL  MBNO  *■*'); 
put  skip  list  I'M)  TEST  run  the  simulation')  ; 
put  skip  list  ('(2)  QUIT  and  return  to  main  menu' 
put  slip  list  ('enter  1-2  and  <cr>:  '); 
get  list  (item): 

if  ( (itea<1)  I  (itea>2) )  then  signal  error  (1); 
if  item  *1  then  do; 

put  skip  list ('Load  SPYTEST.CMD  from  another 
system  CRT/SBC.*): 

put  skip  list  ( 'W&eg^cjmp let e^  enter  0<cr> 
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get  list  (start)  ; 

if  start®=0  then  signal  error (1) 

do  tine  *  l.to  endtiae: 
call  await  (threshold) ; 
threshold  *  threshold  +  1; 
call  load  buffer  (time)  ; 
call  xfer”msg; 
call  advance  evcl; 
call  displayltime)  ; 
end; 
end; 

else  return; 
revert  error  (1) ; 
end  static: 


B.  18117.186 


Prog  Nane  :  1WHT.186 

Date  :  8  June  83 

Written  by  :  Todd  B.  Karsh 

Pgr,  :  Thesis  (1EGIS  Modeling  Group) 

idvisor  :  Professor  Koares 

Purpose  :  This  acdule  checks  to  sae  if  a  asg  has  been 

written  to  OEOOO:5614  of  coeion  aeaory  by  the  Radar 
Scheduler. 

ss3s:ss33s:xs3izaas2isiaii  Msareszssssssassssssss 

Dill 

3333333333333333X333333333  S3Sa:SSSSSS33SSSSSSSS3  = 


3333333333  ==33  =  333X33X23332  13X33X33X33X3333X33X33 

CODE 

====  =  =======  =  =  =  =  =  ====3^=  ==  =  =  ==  =  =  =  ===  =  ======  =  = 


fubiic 


await 


await : 
push  a* 
push  di 
push  si 
push  es 
now  ax,0e000h 
qov  es,ax 
aov  d$ , 06020h 
moy  si,rtx1 
lods  axL  J 
poll  5  r  , .  , 

c»F  ax,es:[di] 
jnz  poll 
pop  es 

"SI  Si 


pop 

ret 


ax 


end 


getcoaaon  aea 
assign  to  eseg 


base 

_Tj.gn  to  eseg  base 
oint  to  eve  addrs. 


«  y 


put 


thr  es 


ft 


ihold 
in  a 


ax  reg. 


coagare  eve  to  thr 
j  if  no  new  asg,  wait 
;  else  return 
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C.  10ADEUFF.PLI 


Prog  Name  :  LOADBtJFF.PLI 

Date  :  31  May  83 

Britten  by  :  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Adviser  :  Professor  Kodres 

Purpose  :  This  module  is  part  of  rhe  Static  Model 

and  will  extract  the  proper  sector  of  output  msgs  (e.g. 
tbl  8s)  from  the  database  on  the  Reiex  DW,  based  on  the 
curTent  value  of  delta  t,  and  place  the  data  in  th9 
common  memory  buffer.  ~ 

♦/ 


load_buffer:  procedure (time_in) 


declare  , 

time  in  fixed, 
send“mess  entry, 
builc  cm3  mess  entry 


<bi|l«V 


declare 

statui 


,  fixed 

jiied  biSlrv 
bil 


many 
static  init(O), 
init 


binary  (15)  , 

7). 'fixed  binary  (7), 

lllfi 


fixed .  binary  (t  5) 
sect  fixed  binaryfj)  , 
word  count  fixed  binary 
mem  Iit(16)  static  init 
msb  bit 1 1 6 L  static  init 
track  fixed  binary  (15), 
head  fixed  binaryt/)  . 
rdw  wrt  bitjlS)  static  init  (•  10 10 '  b4) ; 
/*  "10 ly"  means  the  HBMEX  will  read 


15)  static 
•5500'bU)  , 
♦000a*  b4) , 


(256) 


the 


bard  disk  and  write  to  con. mem.  buffer,  V 


he*d  *  0;  /*  this  sets  head  to  “DM  drive  */ 

/*  This  determines  the  sector  based  on  39  sectors/track  */ 
sect  *  1  ♦  «od{ti*eJLn,4Q) ; 

/*  This  determines  the  track  */ 
track  *  1  ♦  trunc  (ti»e_ia/ J9)  j 


/*  Max  tracks  available 
therexcr,  to  prevent  run 


the  asasx  is  210 
ng  out  of  memory...*/ 


if  track  >  210  then  do: 

put  skip  llstpthe  database  store  is  full.'); 
put  s)dp  list 

V  This  r 'in  is  recorded  as  • ,tiae  in,’  delta  ts.  *)  ; 
put  skm  list 

To  create  a  longer  run,  change  the  value  of  delta  t.'); 
return, 
end; 


/*  This  procedure  builds  the  command  message 
reguicsd  Bor  the  Semex  Data  Warehouse  to  write  the 
data  tables  located  in  the  buffer  corresponding 
to  the  value  of  'time^in*  */ 

call  build  cid  mess 

(rdw^wrt,  status,  tracx,  head,  sect, mem,ttsb,word_couni) ; 

/*  The  procedure  sends  the  command  message  to  the 
Be  sex  Data  Warehouse  to  perform  the  required 


66 


write  operation  */ 
call  send  mess; 
end  load  fcnffer; 


II 


XFEH.J86 


Prog  Name  :  XFER.A86 

Date  j  8  June  83 

Written  by  :  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  module  will  transfer  a  output  msg. from 
the  common  memory  buffer  to  the  common  memory  location 
0E000:5646  to  be  read  bv  the  Track  *  ‘  ' 


xfer  msg: 
T5usn 


Push  di 
push  si 
push  es 
push  ds 
push  ax 
pushf 

mov  axr0eQ00h 
mcv  es»ax 
mov  si,C5500h 
mcv  di,06Q55h 
mov  cx,5 


move  msg: 

mov  ax,es:fsi] 
mov  es:[dij,ax 
inc  si 
inc  si 
inc  di 
inc  di 

loop  move  oisg 
pep! 


; get  common  mem.  base 
; assign  to  essg 


;set  loop  ctr  to 
;  pass  5  words 
;  (one  tbl_8)  . 

jload  word  from  buffer 
;stora  word  into  msg. 
;get  n9xt  word  loc. 

;get  next  word  loc. 

;loop  until  done 


E.  DISPLAY. PLI 


Frog  Same  :  DISPLAY .  FLI 

Date  :  8  June  83 

Written  by  :  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kcdres 

Purpose  :  This  will  display  the  status  of  the  test 
simulation  for  the  RSP  Static  Model,  and  allow  the 
user  to  make  measurements  tc  determine  the  speed  of  the 
SPS  SFY-1 A  Model  execution. 

V 

display:  procedure  (time); 

declare 

time,  fixed# 

endtime  fixed  external; 


/♦put,  listjascii  (26) ,  ascii  (30)  );*/ 

put  skip  list  (*  =«  RSP  STATlfc  MODEL  SIMULATION  =* 

TIME:'  ,time,  *  ENDTIME;  • , endtime)  ; 


put 

put 


skip  (2)  , 
skip  list  (' 


end  display; 
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ADV1EVC. A86 


Prog  Name  :  ADV1EVC.A86 

Date  :  8  June  83 

Written  fcy:  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modelling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  module  will  simulate  the  2adar 
Signal  Processor  sending  a  new  data  asg  to  the 
SPY-1A  Cctrcller  Model. 


Data 


23ft  as 


Cede 


(222X83222  3S23S2322S22S2S2SSS2S2 


28 222SS222S83K  2S3522SS: 

SS  322233232553  35338S  S5SS3 


cseg 

public  advanee^evcl 


advance  evcl: 

ISIS  a? 

push  ax 
bov  ax,0e000h 
bcv  es,ax 
aov  di,06055h 
bcv  ax#es:C  di} 
inc  ax 

nev  €s:[di]#ax 


;  ge^  cob.  aem.  base  to  eseg 
;  point  to  evcl 
;  get  value 

:  increaent  value 
jstore  evcl 


APPENDIX  C 

COMMON  ASSEMBLY  LANGUAGE  LISTINGS 


A.  BLDMISSG.A86 


Prog  Name 
Date 

Written  by 
For 

Advisor 
Purpose 
command  asg 
Warehouse,  to 
operations, 
follows  from 
build  cad 


BLDNESSG.A86 
May  83 

Toad  B.  Kersh 

Thesis  (AEGIS  Modeling  Group) 
Professor  Kodres 

This  primitive  module  is  a  general 
passing  routine  to  the  Remex  Data 
be  used  for  both  Write  and  Bead 
It  expects  to  get  parameters  as 
the  calling  PLI  program: 
mess  (word  0,  word  1,  word  2, 
word  3  high  byte,  word  3 
lew  byte,  word  4,  word  5, 
word  o) 


83sss3assss»ss»ssss8s8as  ssaaaasaassssssssssas: 

Data  Segaent 


*sssa«s 

USES 

sissssaasanaass 

CCMMEM 

EQU 

ssaasssaasaaaassaaaaas 

0E000H 

ESEG 

PUBLIC 

CBG  5400H 

STATUS 

MODIFIERS 

RW 

1 

STATUS 

RW 

1 

TRACK  NO 

RW 

1 

HEAD  SECT 

RW 

1 

MEHJDDR 

RW 

1 

MSB 

RW 

1 

WORD  CNT 

RW 

1 

•  satsasaatisasttacaimatamKataacatsatjaM  ■SQSja»wasa**3«3»a»*»=s  a 

;  Cede  Segaent 

•  ssa  sstaaaB  at  am  ataittamaettai  *«aee*»»ae-a»««nisaceats*«»a 

CSEG 

PUBLIC  EOILCCMD  M 8SS 


BUILD  CMD  HESS: 

PUSH  ES 
POSH  Cl 
PUSH  SI 
POSH  BX 
POSH  AX 
PCSHF 

ROW  AX ,COMM£M 
MOW  ES,AX 
CLD 

MOW  SI ,(  8X  ] 

LCDS  AX 

HCW  M0DIPIEBS,AX 
ADD  EX ,  0  2H  ^ 

MOW  SI ,[  8X3 

LODS  AX 


5  set  source  index  to  point 
;  to  1st  parameter. 

;  AX  *  para  1,  SI  increaented 
;  to  point  to  next  parameter. 

;  point  to  next  parameter  address 
•  set  source  index  to 
; point  to  next  para. 
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END 


BET 


MCV  STATUS,  AX 
ADD  BX,0  2H 
MOV  SI, [EX] 

LCDS  AX 

MCV  TRACK  NO,  AX 
ADD  BX,0  2H 
MOV  SI ,[  BX]  ; 
LCDS  AL 
MOV  AH  ,AL 
ADD  EX  ,  0  2H 
MOV  SI  ,[  BX] 

LCDS  AL 

MOV  HEAD  SECT ,AX 
ADD  BX^lH 
MOV  SI  ,[  BX] 

LODS  AX 

MOV  MEM  ADDR  ,  AX 
ADD  BX,U2H 
MCV  SI  ,  [  BX  ] 

LCDS  AX 
KCV  MSB. AX 
ADD  BX,02H 
MOV  SI  ,[  BX] 

LCDS  AX 

MCV  HORD  CNT  ,  AX 

POPF 

POP  AX 

POP  BX 

ECP  SI 

POP  cx 

ECP  ES 


;  point  to  next  parameter 
{set  source  index  to  point 
; to  next  para. 


;  point  to  next  parameter 
set  index  to  point  to  next 
;  get  byte  para  in  al  rea 
;  move  al  to  ah 


{word  is  now  complete  for 

;  point  to  pext  parameter 
{set  sgurco  index  to 
;pomt  to  next  para. 


; point  to  next  parameter 
{set  source  index  to 
{point  to  next  para. 


{point  to  next  parameter 
{set  source  index  to 
{point  to  next  para. 


address 

address 

para. 

movement 

address 

address 

address 


B.  SHDMESS1.A86 


Prog  Name  :  SNDMESS1.  A86 

Date  :  May  83 

Written  by  :  Toad  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This  primitive  module  sends  the  command 
message  located  in  common  memory  at  0E000:5G00  to  the 
Remex  Data  Warehouse  for  execution,  it  checks  the 
Status  Word  in  the  msg.  for  successful  msg  completion. 


Data  Segment 


f)SEG 


RDW  ERROR 

DB 

1 

BDW“BBSULT 

DB 

1 

BDW'EIB 

DB 

1 

SUCCESS 

SOU 

1 

{code 

for 

opn 

success 

FAILURE 

ECU 

0 

{code 

for 

opn 

failure 

RDW  REACT 

EQU 

08H 

TRIES 

« 

EQU 

05 

{constant 

;  hdh  interface  controller  ports  *»> 


$DW  CMC  REG 

EQU 

70H 

BDW”STAfCS  REG 

EQU 

7  1 H 

BEW“APDR  LD 

EQU 

72H 

BEW“ADEB”HI 

EQU 

73H 

ESEG 

EXTRN  STATOS  SWORE 

i 

•  ^aBassaaasisssssaacsaataissss  aaaaaaaaaassaaisssassaasasaajssaaa 

;  code  segment 

j  sssBessasssnasaxiSiasscaasa  aseaasaaaassaaasssssassaasssaaas 

£sEG 

PUBLIC  SEND.HESS: 


SBND_MBSS: 

POSHP 
POSH  A  t 
POSH  BS 
PUSH  CX 
new  AX,0EQ00H 
MCV  EX, AX 
HCV  CX.TRIES 
SEND  RDM  MESS: 

“IN  XL, ROW  STATUS  REG 
AND  AL  rRDW^BEA DV 


;init.  loop  counter 


CMP 

JNE 

MOW 

GOT 

MOV 

OUT 

MOV 

CUT 

CHECK  RDW 
HCV 
CMP 
JE 
CMP 


AL.08H 

SEND  RCW  MESS 
AL.1CH  ” 

ROW  CHE  REG,  AL 
AX,U54  00H 
RDW  ADER  LO,  AL 
AL.XH 

RDW  ADCR  HI, AL 
RESULT:” 

IX, STATUS 
A  X  .SUCCESS 
aow  SUCCESS  READ 
AX , PAX  LURE  ” 


{check 
;to  pr 

■■-lip? 


if  inte 
rocess  cm 
? 

not 


rface  ready 
a  packet... 


repeat 


;load  extended 
;offset  of 
;transfer 

{transfer  high 


address 


Sacket 
yte 

byte 


;  read 
{check 


status  word 
for  success 


check  for  failure 
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JNE  SDH  RETRY 
JMPS  CHECK  RDH  RESULT 
BDii  BETEY  •  —  — 

“  HCV  RDH  ERROR# AL  {save  error  code 
MOV  STATUS.O  {clear  status  word 

LOOP  SEND  RDH  HESS  {loop  if  counter  <>  0 
MOV  RDH  RESULT. OF FH  {return  failure  code 
JMPS  8DE  EXECUTE  RET 
RDH  SUCCESS  RElD: 

“  MOV  R'UH  RESULT#00  B  {return  success  code 
BDH  EXECUTE  1ET  : 

~  POP  CX" 


kimm  d 

SPY- 1 1  MODEL  SIMULATION  PROGS AM  LISTINGS 


A.  SEYTEST.  PLI 


Prog  Bane  :  SPYTEST.ELI 

Dat9  :  8  June  83 

Written  by  :  Todd  B.  Kersh 

For  :  Thesis  (AEGIS  Modeling  Group) 

Advisor  :  Professor  Kodres  „  , 

Purpose  :  This  is  a  test  module  that  simulates  the 
operation  of  the  NPS  SPY-1A  Model.  It  will  update  the 
tabl  58  data  in  common  memory  upon  the  event  count  update 
from“the  Static  Model,  after  a  delay  loop  that  simulates 
the  operation  of  the  Track  Processor  and  Radar  Scheduler. 


/♦  This  will  initiate  the  eventcouats  to  0  */ 
call  init; 

do  while  1*  1  *  b)  ;  . 

call  advance  evc2;  /*  This  simulates  sending 

dwell  cad.  msg.  V 

call  await  1  (threshold)  ;  /*  wait  for  results 


a  new 


>r  res _ 

e.g.  tbl^.3  */ 

/*  This,  is  a  delay  loop  simulating  SPT-1A  Model 
processing  time.  V 


threshold  *  threshold  ♦ 
do  i  *  t  to  50  i 

cut  Skip  listC  SPT-1  IS  PROCESSING  DATA...*); 
end; 

end;  /*  while  V 
end  spy^test ; 
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B.  ISIT.A86 


;Prog  Naae  :  INIT.A86 

;Date  :  19  Jane  83 

; Written  by  :  Todd  B.  Kersh 

;Por  :  Thesis  (AEGIS  Modeling  Group) 

;Advisor  :  Professor  Kodres 

;Purpose  :  This  aodale  initiates  the 

jaeaory  locations  for  the  eventcounts  to  0. 

•  SS3Za  =  32SX:aS3S3SS3SS«S3S  333333S2Z3  33  333S3333S3 

;  Data 

• 2332X333232SS33383333333SS 3333333333 333333333333 

dseg 


eseg 
public 


evc1,evc2 

020h 

org  06 

evc2  rw 

1 

evcl  rv 

1 

;33333  3aS333 

Code 

isasassassss 

8X3331 

X3  3XX: 

8X33SS3S3 23Z33Z' 


>33333333X3335 


end 


,ic 

iait 

• 

push 

ax 

push 

es 

aov 

ax,  OeOOOh 

acv 

es,ax 

;sat 

exeg  base  to  coa 

acv 

ax,0 

;set 

ax  to  0 

BOV 

evc1,ax 

jset 

eventcounts  to  0 

acv 

evc2,ax 

pop 

es 

pep 

ax 

rat 
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HAITI.  186 


eve.  has 
by  the 


0.  ADT2E1C.A86 


;Prog  Name  :  ADV2EVC.  A85 

;Date  :  19  June  83 

;Written  by  :  Todd  E.  Kersh 

;For  :  Thesis  (AEGIS  Modeling  Group) 

{Advisor  :  Professor  Kodres 

;Purpcse  :  This  icdule  will  simulate  the  Radar 

scheduler  sending  a  new  dwell  command  to  the  RSP. 
• 

; _  Eata 

fiseg 


eseg 

extrn  evc2:word 
• 

•sass sk— —  —  -3-ffl-SS3S-  a  —  a  aa  -  a  —a  —  — 

;  Ccde_  _  _ _ _ 

• 

f 

CSQQ 

public  Advance_evc2 

advance  evc2: 
pusE  es 
push  ax 

acv  ax,0e000h 

aov  es,ax  ;  get  addr.  of  comm. mem.  base 

;  in  eseg 

inc  evc2;  advance  eventcount 
pep  ax 
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APPENDIX  E 

OBJECT-ORIENTED  DESIGN  OP  THE  DYNAMIC  MODEL 

A.  DEFINE  THE  PBOULEM 

A  system  is  required  that  will  interface  with  existing 
SPY-1  A  Badar  Controller  modules  and  simulate  the  Signal 
Processor  of  the  Hadar.  The  required  interface  will  actu¬ 
ally  include  the  Badar  Output  Module  and  the  Radar  Return 
Module,  and  the  Beam  stabilization  Modules.  The  Signal 
Processor  Simulator  must  contain  a  database  representing  the 
environment  the  Radar  will  probe  for  target  tracks.  The 
database  must  be  user  changeable  at  any  given  time  during 
the  operation  (i.e.  add  target  tracks,  delete  target  tracks, 
and  change  target  tracks)  so  that  the  logical  operation  of 
the  5PY-1A  Radar  Modules  (Radar  Scheduling  and  Track 
Processing)  can  be  tested  and  explored, 

B.  DEVELOP  IN  INFORMAL  STRATEGY 

The  database  for  the  signal  processor  will  capture  the 
information  for  each  target  at  discrete  time  intervals 
needed  tc  define  it's  position.  The  inforaation  maintained 
about  each  target  track  will  include  ir's  actual  position 
(x,y,z,r)  and  it's  acceleration  components  (ax,ay,az,ar)  at 
a  discrete  time  interval  (t)  *  Interaction  operations  that  a 
user  may  request  include  -  initiation  of  a  target  track  over 
a  range  of  time  (Ti  — >  Ta),  deletion  of  a  previously 
entered  target  track  throughout  all  or  part  of  it's  initi¬ 
ated  range  of  time,  and  changing  a  previously  defined  target 
track  at  any  time  during  it's  pre-defined  time  range.  The 
user  will  also  be  able  to  start  and  srop  the  simulation  at 
any  tiee.  The  user  will  have  a  two  dimensional  display  of 
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the  radar  environment  with  current  tracks  and  relative  posi¬ 
tions  symbolized  during  the  simulation.  A  status  report  of 
current  targets  will  he  available  while  in  a  non-running 
node  to  assist  the  user  in  the  environment  definition. 

C.  F0BBI1IZB  THE  STHATBGI 

1  •  Identify  the  objects  and  their  Attributes 

a.  S  IE  OL  ATI  0  HOOPER  ATI  OHS 
t.  TEACKJJATA: 

Target  information: 
target^iD 
actuals  position 
acceleration 
time 


2. 


Ida 


on  th§  Objects 


a.  SIHOLATIOH^oriBATIOHS 
fc.  Dim  AT: 

Start 

stop 

C.  TBACK^DATI: 

Status_Eepert 

Quit 

Targetjtafor tation: 
create 
dele  te 
change 
Database 
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Establish  the  Interfaces 


f 


SIMULATION  0?NS 
(packagef 
creata  tgt 
deletev'tgt 
change”tgt 
status'rpt 
quit  ~ 


SIMULATION  0 PNS 
(subprogras) 


DISPLAY 
(package) 
start 
stop 


TRACK  DATA 
*>  (package)  < 


♦ 


t 


tgt  Info 
(package) 
tgt  record 


datIbase 
(package) 
active  records 
data 


figure  B.  1  Object-Oriented  systea  Graph, 


tt«  Cede  |h&  Package  Specifications  Ml 


package  TSACKDATA  is 
package  ^TTwINFO  is 

end  TGT^IBPO ; 

package  DATABASE  is 

end  CITAEASE; 
end  TRACK_DATA; 

package  TOT  INFO  is 

type  ENDJFIHB  is  constant  :a  1000; 
type  COCtfOIHATES  is  (X.T.S.H): 
type  ACCEL  VECT08S  is  (  AX(  At  *A2,  AR)  ; 
tyoe  DISCRETE  TIMS  is  range  ..  END  TIME; 
type  TARGET  13  record 

LOCATION  :  COORDINATES: 

ACCELERATION:  ACCEL  VECTORS; 

TINE  :  DISC  RETS  TINE; 

end  record; 
end  TGT_IBPQ; 


package  DATABASE  is 
use  TGT  INFO; 

MAX  RECORDS  ;  constant  :=  20; 

type  RECORD  INDEX  is  range  0  ..  MAX  RECORDS; 

typ i  TRACK  'RECORDS  is  array  ( RECORD'INDEX)  of  TARGET; 

ACTIVE  TGT S'  :  RECORD  INDEX; 

DATA  “  ;  TRACK  1EC0RDS; 

end  DATAEASE; 

with  TRACK  DATA; 
use  TRACK“EATA; 
package  SIlOLATICN  OENS  is 

type  OPERATICN“is  (CREATE  TGT  /DELETE  TGT/  CHANGE  TGT/ 

STAT0S~RPT/Q0IT) 
function  GET  return  OPERATION; 
procedure  CREATE  TGT; 
procedure  D ELET B“TGT ; 
procedure  CHANGE’TGT; 
procedure  STATUS"RPT; 
procedure  QUIT; 
end  SIMULATION  OPUS; 


with  TRACK  DATA; 
use  TRACK- EAT  A; 
package  DISPLAY  is 

type  CONTROL  is  (START,  STOP) 
function  RUN  return  CONTROL; 
procedure  START; 
procedure  STOP; 
end  DISPLAY; 


Further  programming  would  design  and  build  the  subprograms, 
functions,  and  procedures  defined  by  these  package 
specifications. 
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APPENDIX  F 

SIGNAL  PHOCESSCE  MODEL  QSEBS  MANUAL  (TEE.  1.0) 

A.  GEMBBAL 

This  manual  is  for  use  with  the  NPS  AEGIS  Modeling  Group 
AN/SPY-1A  Badar  Controller  Model:  signal  Processor 

Emulation  version  1.0.  It  does  not  explain  the  structure  of 
the  modules  that  make  up  the  program,  only  it's  functional 
components  and  how  they  might  be  utilized  to  test  the  SPY-1  A 
Model.  For  further  information  about  the  program  design  and 
implementation,  see  Kersh,T.B.,  signal  Processor  Interface 
Siffulflticft  of  the  AN/SPY -1 A  Badar  Controller,  Masters 
Thesis,  Naval  Postgraduate  School,  Monterey  California  1983. 

The  manual  is  divided  into  the  two  major  functional 
areas:  developing  the  target  database  to  be  stored  in  the 
BEMEX  Data  Warehouse,  and  running  the  Static  Model  of  the 
Signal  Processor  against  a  simple  SPY-1  A  simulator.  It  will 
be  assumed  that  any  potential  user  of  this  system  is 
familiar  with  the  boot  procedure  for  the  Eemex  Data 
Warehouse  disk  system.  Assuming  the  user  has  booted  from 
the  EEMEX  B:  drive  and  logged  into  the  BEMEX  D:  drive,  place 
the  Signal  Processor  system  disk  in  the  C:  drive,  and  type: 

D>C:ESP  <rsturn> 

At  this  point  the  Signal  Processor  Emulation  System  will 
load  and  the  remaining  database  development  and  model  opera¬ 
tion  will  be  menu  driven. 

The  following  functions  are  available  within  the  Signal 
Processor  Interface  Simulation  - 
TABGET  DATABASE: 

1.  CHEATE  the  inital  target-list  and  initial  database. 
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2.  DELETE  any  targets  at  any  specified  descrete  time. 

3.  CHANGE  the  parameters  of  the  parametric  equations 
represent  ing  the  target  tracks  at  any  specified 
descrete  time. 

4.  PRINT  the  current  target-list  tc  the  terminal  screen 
cr  the  printer  at  the  specific  descrete  time  repre¬ 
sented  by  the  target-list. 

SIMULATION: 

1.  HON  will  execute  the  Static  Model  in  a  test  environ¬ 
ment  to  be  used  for  testing  the  Signal  Processor 
Interface  Simulation  System. 

After  development,  the  user  can  document  the  targets 
contained  in  the  target-list  at  a  particular  descrete  time  , 
so  that  he  has  a  hard-copy  record  of  the  trend  of  his  data¬ 
base.  This  feature  will  be  important  in  determination  of 
the  effect  of  different  target  combinations  and  densities  on 
the  SEY-1A  Controller  Model.  The  Signal  Processor  Interface 
Simulation  Tar get- Database  development  system  should  be 
usable  in  conjuction  with  other  testing  systems  devised  by 
future  AEGIS  Group  members  for  the  logical  testing  of  the 
SPY-1  A  system. 

E.  CCNSTBUCT  TARGET  DATABASE 
1.  jjai,a  Menu 

Just  prior  to  the  display  of  the  main  menu,  the 
program  will  ask  for  user  input  defining  the  descrete  time 
intervals  to  be  used  for  the  update  of  the  buffer  used  by 
the  Target-Database  system.  The  ratio  of  dwell  commands 
received  from  the  Radar  Scheduler  Module  to  the  target- 
buffer  update,  multiplied  by  the  actual  turnaround  time  of 
the  SP-1A  Controller  Model  will  be  the  real-time  achieved  by 
the  system.  The  user  may  assign  values  from  .1  to  1  to  this 
ratio  value.  The  next  question  asked  of  the  user  is  how 


long  th«  simulation  will  run.  The  maximum  possible  length 
is  dependent  on  the  storage  space  available  on  the  REMEX 
Data  Warehouse,  and  the  time  is  based  on  the  average  assumed 
dwell  command  interval  time  received  from  the  SPY-1 A  Radar 
Controller  Model.  To  determine  the  simulation  run  limit  in 
terms  of  descrete  time  increments,  one  must  realize  that 
each  descrete  time  increment  is  in  one-to-one  correspondance 
with  the  sectors  used  to  record  the  database  on  the  REMEX. 
Therefore,  since  there  are  39  sectors  per  track,  and  210 
tracks  available  for  use,  there  are  8190  available  descrete 
time  intervals  available  for  a  simulation  run.  The  real-time 
length  for  the  simulation  run  is  then  dependent  on  the 


***  M AIK  MEND  *** 


What  course  of  action  do  you  wish? 

(1)  CREATE  a  database  of  tracks 

®u  must  do  this  first) 

ETE  a  track  from  the  database 
3)  CHANGE  a  track  on  the  database 
print  the  current  target  list 


After  a  database  is  satisfactory  you  may: 

(5)  RON  a  simulation 

(insure  the  rest  of  the  SPY-1  Model  is  setup) 

(6)  QOIT  and  return  to  the  operating  system 
(enter  1-6  and  <cr>) : 


Figure  ?• 1  Signal  Processor  Emulation  Main  Menu. 

descrete  time  ratio.  Assuming  a  negligible  time  for 

updating  the  target  buffer  from  the  REMEX,  and  a  turnaround 
response  time  from  the  SPY-1A  controller  Model  of  .001 
seconds,  if  a  ratio  of  "I"  were  chosen,  the  maximum  time 
available  for  a  simulation  run  would  be: 
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1.  "1M  second  =  .001  sec.  *  1000  {or  1000  dwell  commands 
issued  per  buffer  update) 

2.  since  the  target-buffer  is  updated  once  every  second, 
there  are  8190  seconds  of  maximum  simulation  time 
available. 

The  next  item  appearing  on  the  screen  is  the  Main 
Menu.  The  first  thing  required  is  to  build  a  database  in 
the  REMEX  Data  Warehouse.  To  do  this,  the  user  will 
initially  pick  choice  (1)  CREATE.  After  initializing  his 
Database,  the  user  be  able  to  move  forward  in  descrete  time 
and  delete  target  tracks  completely,  or  just  change  the 
parameters  cf  the  track.  It  is  suggested  that  the  user  use 
option  (4)  PRINT  after  each  iteration  of  rhe  previous  two 
options  and  after  CREATE,  to  maintain  a  record  of  the  modi¬ 
fications  made  on  the  database.  When  the  user  has  finished 
with  his  Target  Database,  he  may  request  to  (5)  RON  a  Static 
Modal  simulation.  In  this  mode  the  SPY-1  A  controller  Model 
Simulator  "SPYTEST”  is  designed  to  test  the  static  Model. 
Further  instructions  cn  the  use  of  this  option  are  discussed 
in  Section  C.  Of  course,  at  any  time  after  the  user  has 
returned  to  the  Main  Menu,  he  may  choose  option  (6)  QUIT  to 
return  tc  the  operating  system. 

2 •  create  Database 

To  use  the  signal  Processor  Interface  Simulator,  a 
Target-Database  must  first  be  constructed.  A  Target-List  is 
used  which  contains  target  data  to  construct  a 
Target-Database.  The  parameters  used  to  set  up  the 
Target-List  for  each  target  are  the  constant  values  used  in 
the  parametric  equations  shown  in  Figure  F.3  These  parame¬ 
tric  equations  derive  from  Boone,  N.A.,  A  Multimicrococessor 
Approach  to  simulate  fo£  the  AEGIS  AN/SPY-1  A  Radar 

Cpntrcllei;,  Masters  Thesis,  Naval  Postgraduate  School, 
Monterey  California,  198  1.  Boone’s  work  concerns  the 
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===  CREATE  TARGET  MODULE  === 

Initiate  target  #  J  „  „  ^ 

Parametric  Equations?  (1,2, 3, or  4)  :  _ 

X  range  (a)?  (-256,+  25o)na: 

Y”range  (u)?  (-256. ■♦•2561  nm: 

X“velccity  (b)  ?  (-52 ,  +32)  m/sec? 

Y"velocity  (v)  ?  (-32, +32)  m/sec: 

X“acceleration  (c)  ?  (-.0 15625,  +  .UT5625)  m/sec/sec: 
^“acceleration  m?  (-.0 15625, +  .015625)  m/sec/sec: 
Z”altitude  (d)  ?  (0,20000)ft: _ 

create  more  targets?  (Y  or  N) : _ 


Figure  F.2  CHEATS  Function  Menu. 


(1) 


a  +  b*t  ♦  c*t*t 
u  +  v* t  ♦  w*t*t 
d 


(2) 


a  ♦  b*t  +  c*t*t 
u  ♦  v*sin(w*t) 


<3) 


x (t)  *  a  +  b*cos  (c*t) 
y  t  a  u  ♦  v*t  ♦  w*t*t 

Z  (t  ad 


(4) 


x(t 

It 

z  (t 


a  ♦  b*cos(c*t) 
u  ♦  v*sin(w*t) 
d 


Figure  F.3  Parametric  Equations. 

simulation  of  the  AEGIS  Command  and  Decision  functions,  and 
these  equations  were  utilized  to  maintain  compatiblity 
throughout  the  Model.  After  defining  the  parametric  equa¬ 
tion  for  the  first  target,  the  user  may  choose  to  define 
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further  targets  and  will  be  prompted  similarly  as  previously 
shown.  When  he  is  satisfied  that  the  target-list  is 
complete,  he  may  indicate  that  no  more  targets  are  to  be 
created,  and  he  will  te  returned  to  the  Main  Menu.  At  than 
time  it  is  recommended  that  the  user  request  a  PRINT  of  the 
initial  target-list  fcr  future  reference. 

3.  Delete  Targets 


. . . 

==*  DELETE  TARGETS  MODULE 

WHAT  TARGET  DO  YOU  WISE  TO  DELETE?  » 
(TGT.  NOM.  RANGE  1- _ ): _ 


Figure  P.4  DELETE  Function  Menu. 

Pricr  to  the  Delete  Menu,  the  user  will  be  asked  "At 
what  time  do  you  want  to  delete  a  target?".  The  user  is 
being  asked  to  define  the  descrete  time  within  his  previ¬ 
ously  defined  range  of  descrete  time  that  he  wishes  to 
delete  a  previously  defined  target.  It  is  important  that  the 
user  have  developed  a  plan  for  target  modifications  based  on 
his  defined  descrete  time  range,  since  the  Target-Database 
development  routine  will  not  allow  one  to  recover  deleted 
targets.  After  answering  the  time  question,  the  Delete  menu 
will  be  displayed,  and  the  target  list  appropriately 
updated.  After  Deleting  a  target,  the  user  will  be  prompted 
to  "continue  (Y/N)?".  He  may  answer  Y(es)  to  delete  more 
targets  or  N<o)  to  return  to  the  Main  Menu. 
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4 .  Change  Targets 

The  Change  choice  from  the  Main  Menu  will  first 
prompt  the  user  requesting  what  time  he  wants  to  change  a 
target,  within  his  predefined  descrete  time  range.  After 
answering,  the  user  will  see  the  Change  menu  (see  Figure 


===  CHANGE  TARGETS  BO  DOLE  -== 

WHAT  IS  THE  TARGET  NUMBER  TOO  WISH  TO  CHANGE? 
(TGT.NUB.  RANGE  1- _ )t _ 

WHAT  DATA  ITEM  IS  TO  BE  CHANGED? 

(1)  PARAMETRIC  EQOATION 

(2)  EQOATION  PARAMETERS _ 

(if  the  choice  is  one.  then:) 

WHAT  IS  THE  NEW  EQOATION  NOMBER  (1-4)?  _ 

(if  the  choice  is  two  then:) 

WHAT  ARE  THE  NEW  PARAMETERS: 

Arrange  (a)?  (-256  ,+256)  nm:  _ 


Z.alt.  <d)  ?  (0,200  00)  ft: _ 

(and  fcr  either  choice..) 

DO  YOO  WISH  TO  CHANGE  ANOTHER  TARGET? 

<*/»): _ 


Pigore  1.5  CHANGE  Function  Henu. 

F.5).  Again,  let  it  be  emphasised  that  it  is  important  tc 
hate  a  plan  for  the  cterall  target  database  since  it  is  not 
possible  to  gracefuly  go  backward  in  sequential  time  as  a 
target  database  is  developed.  Also,  it  is  again  recommended 
to  the  user  to  obtain  a  print  of  the  Target- List  as  seen  as 
you  return  to  the  Main  Menu. 
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C.  BOM  STATIC  MODEL 

The  SEY-1A  Controller  Model  Simulator  "SPYTEST.CMD"  is 
provided  as  a  tool  to  test  the  Radar  Signal  Processor 
Interface  Simulation  Static  Model.  ,•SPYTEST.CMD,,  is  just  a 
simple  eventcount  and  sequencer  module.  It  contains  a  delay 
loop  to  simulate  the  time  between  the  receipt  of  a  “raw 
data”  message  from  the  Signal  Processor  Interface,  the 
subsequent  processing  of  the  target  data,  and  the  resultant 
dwell  command  message  generated  to  the  Signal  Processor 


===  BSP  STATIC  MODEL  === 
.version  1,0  dune  03 


At  this  point  you  should  have  created 
a,  database  and'  are  now  ready  to  run 
the  Static  Model. 


HI 

ent 


STATIC  MODEL  MENU 
TEST  run  the  simulation 
QOIT  ana  return  to  main  menu 
er  1-2  and  <cr>; 


Pigure  F.6  STATIC  MODEL  Function  Menu. 

Interface.  The  delay  loop  is  arbitrarily  configured  at  this 
time,  and  the  user  should  consider  contriving  a  delay  that 
more  closely  represents  the  turnaround  time  the  SPY-1A 
system  should  provide.  When  entering  the  test  mode,  the 
user  will  be  prompted  to  "Load  SPYTBST.CMD  from  another 
system  CBT/SBC.  When  complete,  enter  "0"<cr>  to  begin  ". 

When  the  SPY-1  A  Controller  Simulator  has  been  initiated, 
the  Static  Model  will  begin  operation  after  the  uses  has 
typed  M0<cr>".  The  display  for  the  Static  Model  is  shown  in 
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===  BSP  STATIC  MODEL  SIMULATION  === 
TIME:  ENDTIME:  _ 


- - » 

Figure  F.7  STATIC  MODEL  Display. 

Fig.  F.7,  and  provides  the  user  with  only  a  minimum  anoount 
of  inforaation  to  deteraine  the  progress  and  speed  of  execu¬ 
tion  for  the  SPY-1  A  Model.  Since  the  Static  Model  and  its 
inherent  display  functions  will  be  part  of  the  timed  data 
gathered  by  the  user#  it  is  recommended  that  the  SPY-1  A 
Controller  Simulator  be  utilized  to  measure  the  Static  Model 
tiae.  The  aeasured  Static  Model  run  time  can  be  used  in 
future  rur-tiae  testing  of  the  NPS  SPY-1A  Controller  Model 
to  determine  net  SPY-1A  Controller  Model  achievable  speed. 
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